Создание большого числа заказов на продажу. Падение скорости загрузки. - DAX: Программирование

bobski · 05.03.2009, 09:04

Доброго всем дня, уважаемые знатоки, вопрос следущий. Имеется текстовый файл с операциями из другой системы (не Ax), разделитель ";" читаем его используя класс ASCIio, тянем контейнерами построчно.
Данные каждой строки проверяются на правильность. Если проверка пройдена, создатся заказ (если в строке указан новый номер документа) и строка по проверенной строке-контейнеру.
Затем в контейнер тянется следующая строчка. Процесс отражается в прогресс баре.
Выгладит код по созданию примерно так:

X++:

//Создание Заказов на продажу
static void SalesOrderCreation(Args _args)
{ 
SalesTable salesTable; 
NumberSeq NumberSeq; 
SalesLine salesLine; 
InventDim IDim; 
; 
ttsbegin; 
NumberSeq = NumberSeq::newGetNumFromCode(SalesParameters::numRefSalesId).numberSequence);
salesTable.SalesId = NumberSeq.num(); 
salesTable.initValue(); 
salesTable.CustAccount = "некий клиент";
salesTable.initFromCustTable(); 
salesTable.InventLocationId = "некий склад"; 
salesTable.insert(); 
//..............строки
salesLine.clear(); 
salesLine.SalesId = salesTable.SalesId; 
salesLine.ItemId = "некая номенклатура";
IDim.InventColorId ="ххх"; //Измерения
IDim.InventLocationId = "ууу"; 
IDim = InventDim::findOrCreate(IDim); 
.............................. // Ещё всякое заполнение полей
salesLine.InventDimId = IDim.inventDimId; 
 salesLine.createLine(true,
  true,
  true,
  true,
  false,
  false,
  true,
  false,
salesLine.InventTransId);
ttscommit; 
}

Проблема же заключается в:
В самом начале затяжки файла (120000 операций) процесс идет очень резво - примерно по 300 записей за такт и оставшееся время оценивается 7 минут (по данным прогресс бара). С течением времени первый из показателей плавно снижается, соответственно оцениваемое время растет. На рубеже в 20000 записей данные выглядят так - операций за обновление прогресс бара ориентировочно = 50, а время до завершения = 22 минуты. Становится ясно, что до конца загрузки система не дотянет. От этого становится неимоверно грустно. Как добиться того, что бы показатели скорости обработки не падали? В каком направлении копать? Возможно нужно очищать память или ещё что-нибудь? Подскажите, не оставте без внимания. Заранее благодарен.

Sada · 05.03.2009, 09:12

120000 заказов на продажу(судя по джобу), живущих в одной транзакции.

А вообще разделите этот файл штук на 5, авось проглотит

Eldar9x · 05.03.2009, 09:21

Цитата:

static void SalesOrderCreation(Args _args)

попробуйте плюс к предыдущей идеи от Sada перенести работу полностью на сервер.
Машина там должна быть скореее всего помощнее. Файл, естно, тоже на серваке должен быть.
Попутно избавитесь от трафика между клиентом

bobski · 05.03.2009, 09:29

Прошу прощения за корявый код, это примерный джоб с процессом записи, а проблема в рабочем паблик методе

. На самом деле в пределах одной транзакции одновременно живет только одна запись. Неважно в STable или SLine.
Разбить-то оно конечно можно, но вот только хочется, что бы скорость не падала.

Sada · 05.03.2009, 09:34

паблик метод в студию!

А вообще перенесите выполнение кода на сервер. Мож утечка памяти? КР какой? Аксапта какая?

bobski · 05.03.2009, 09:49

Да, верно, забыл указать версию. AX 4.0 SP2 международный функционал.
А вот собственно и код.
Получаем строку файла в контейнер, проверяем её. Если проверка true, то выполняется след. код. Дальше всё повторяется до самого конца файла.

X++:

void SalesHeaderCreation(Container _Data_Container)
{
  SalesTable            SH;
  SalesLine             SL;
  InventTable           IT;
  CustTable             CT;
  SalesTableType        SalesTableType;
  Boolean               IncreaseLineNo;
  SalesType             SalesType; //Заказ на продажу/Возвраты : 3/4
  NumberSeq             NumberSeq;
  InventDim             InventDim;
  SysDim                JurFace;
  InventLocation        InventLocation;
  NumberSequenceCode    SeriesNum;
  NumberSequenceReference NumberSequenceReference;
  ReturnActionDefaults  ReturnActionDefaults;
  #define.Return("Возврат")
  #define.Sells("Продажа")
  #define.KZT("ТНГ")
  #define.VAT0("НДС0")
  #define.VATWOUT("БЕЗНДС")
  #define.VATTRUE("НДС ТРУ")
  ;
 
  // СОЗДАЕМ ЗАГОЛОВОК ДОКУМЕНТА, если предыдущий номер был такой же
  if (PreviousDocNoSm != conpeek(_Data_Container,3))
  {
    //нужен новый номер документа.
    ttsbegin;
    SH.initValue();
    NumberSeq = NumberSeq::newGetNum(NumberSeqReference::findReference(typeId2ExtendedTypeId(typeid(SalesId))), true);
    SH.SalesId = NumberSeq.num();
    PreviousDocNoSm = conpeek(_Data_Container,3);
    PreviousDocNoAx = SH.SalesId;
    LineNo = 1;                                             //Номер строки в таблице строк
    SH.SalesType = 3;
    JurFace = conpeek(_Data_Container,23);
    SH.CustAccount = conpeek(_Data_Container,5);            //Счет клиента
    SH.initFromCustTable();
    SH.SalesStatus = 1;                                     //Открытый заказ
    if (conpeek(_Data_Container,6)=="да")
    {
       SH.InclTax = true;
    } else {
       SH.InclTax = false;
    }
    SH.CurrencyCode = conpeek(_Data_Container,10);          //Валюта
    if (!SH.CurrencyCode)
        SH.CurrencyCode = #KZT;                             //Валюта
    SH.ShippingDateRequested = str2date(conpeek(_Data_Container,2),123);  //Дата отгрузки
    SH.ReceiptDateRequested = SH.ShippingDateRequested;
    sh.FixedDueDate = str2date(conpeek(_Data_Container,9),123);
    SH.DlvMode = strfmt(conpeek(_Data_Container,7));        //Способ оплаты
    SH.PaymMode = conpeek(_Data_Container,8);               //Способ поставки
    SH.Dimension[1] =  JurFace;         //Юр Лицо
    SH.Dimension[5] = 'ДА';
    SH.insert();
    increaseLineNo = false;
    ttscommit;
  } else {
    increaseLineNo = true;
  }
 
                                // СОЗДАЕМ СТРОКИ ДОКУМЕНТА через PreviousDocNo
 
  ttsbegin;
  Select firstfast * from SH where SH.SalesId == PreviousDocNoAx;
  JurFace = SH.Dimension[1];
  SL.clear();
  SL.initValue();
  SL.SalesId = PreviousDocNoAx;
  If (IncreaseLineNo)
    {LineNo+=1;}
  else
    {LineNo=1;}
  SL.LineNum=LineNo;
  SL.ItemId = conpeek(_Data_Container,11);                  //Номенклатура Номер
  Select firstfast * from IT index hint ItemIdx where IT.ItemId == SL.ItemId;
  SL.initFromSalesTable(SH);
  SL.initFromCustTable();
  InventDim.initValue();
  InventDim.inventLocationId = conpeek(_Data_Container,12);
  InventDim = InventDim::findOrCreate(InventDim);
  SL.InventDimId = InventDim.inventDimId;
  switch (conpeek(_Data_Container,20))
  {
  case "0" :
    SL.TaxItemGroup = #VAT0;
    break;
  case "Нет" :
    SL.TaxItemGroup = #VATWOUT;
    break;
  default :
    //SL.TaxItemGroup = #VATTRUE;
    break;
  }
  SL.LedgerAccount = conpeek(_Data_Container,22);
  SL.Dimension[1] = SH.Dimension[1];
  SL.SalesQty = conpeek(_Data_Container,13);                //Количество.
  if (SL.SalesQty > 0)
  {
    SL.QtyOrdered = SL.SalesQty;
    SL.RemainSalesPhysical = SL.SalesQty;
  }
  SL.createLine(true,true,true,true,false,false,true,false,SL.InventTransId);
  SL.ChangeCreatedDateLine(str2date(conpeek(_Data_Container,2),123));
  
  SL.lineAmount = conpeek(_Data_Container,18);              //Чистая сумма ТМЦ
  select firstfast ReturnActionDefaults;
  if (conpeek(_Data_Container,1)==#Return)
            SL.ReturnActionId = ReturnActionDefaults.ReturnActionId;
  Sl.QtyOrdered = Sl.SalesQty;
  SL.ReceiptDateRequested = str2date(conpeek(_Data_Container,2),123);
  SL.ShippingDateRequested = SL.ReceiptDateRequested;
  SL.update();
  ttscommit;
}

**mazzy** · 05.03.2009, 09:55

Скорее всего, у вас установлен Recovery model = Full на SQL-сервере.
Это значит, что все транзакции сохраняются до бэкапа. Из-за массовой вставки у вас безумно растет transaction log на SQL-сервере. А поскольку у вас идет постоянное замедление то рискну предположить, что шаг роста слишком маленький и львиную долю времени SQL-сервер тратит не на выполнение транзакций, а на увеличение файла.

Если это так, то увеличивайте инкремент для trnasaction log или делайте чаще бэкапы. А еще лучше курите админские доки.

Кстати, эффект когда на прогресс-бар показывает постепенное замедление связан с тем, что прогресс-бар использует среднюю оценку - он усредняет быстровыполненные операции с медленно выполняющимися последними. Поскольку медленно выполняющихся становится все больше, то и среднее потихоньку увеличивается, при этом потихоньку увеличивается и оценка оставшегося времени. А на самом деле, скорее всего, с какого-то времени все операции у вас выполняются одинаково медленно

Если вы покурили админские доки, но это не помогло,
то есть другой момент:

Цитата:

Сообщение от bobski

X++:

NumberSeq = NumberSeq::newGetNumFromCode(SalesParameters::numRefSalesId).numberSequence);
salesTable.SalesId = NumberSeq.num(); 
...
ttscommit; 
}

Проверьте, не используете ли вы непрерывную номерную серию для заказов.
Если используете непрерывную, то исправьте код - у вас не хватает вызова метода NumberSeq.used().
Вы не фиксируете факт использования номера, в итоге список незафиксированных номеров у вас растет со старшной силой.

**mazzy** · 05.03.2009, 10:42

Цитата:

Сообщение от bobski

X++:

void SalesHeaderCreation(Container _Data_Container)
{
...
    if (conpeek(_Data_Container,6)=="да")
...
    SH.Dimension[5] = 'ДА';
}

Охерительно!
Вы бы в условии хотя бы strlwr использовали что-ли...
не говоря уже о значениях "Д","Y","Yes", "1".

belugin · 05.03.2009, 10:47

Цитата:

Сообщение от mazzy

Охерительно!
Вы бы в условии хотя бы strlwr использовали что-ли...
не говоря уже о значениях "Д","Y","Yes", "1".

В аксапте сравнение регистронезависимое. Для регистрозависимого надо использовать strCmp

Wamr · 05.03.2009, 10:51

bobski, у вас во внешнем цикле по файлику временная таблица какая-нибудь не используется (покажите джобик)?

bobski · 05.03.2009, 10:54

Все верно, Сергей. Модель восстановления - полная. Серия непрерывная. А вот с прогресс баром это интересно.
Я его обновляю после каждой затяжки, каждой из строк.

progress.setText(strfmt("Обработано записей: %1", CurrentOperationProgress));

Ясное дело, что обновляется прогресс бар через определенный промежуток времени. Допустим, что каждую секунду. Стало быть такт = 1сек. Так вот в самом начале процесса загрузки число обработываемых строк за такт около 300. Постепенно, при обновлении прогресс бара число обработанных за такт строк снижается. И к пятой-шестой минуте снижается до позорных 50 за такт. Странно.

Прошу прощения за следущий вопрос: где увеличить инкремент для trnasaction log?

Sada · 05.03.2009, 10:59

Прогреcc бар сделан для пользователей, чтобы имитировать процесс участия.

Зачастую показывает всякую хрень.

ice · 05.03.2009, 11:02

а для чего на каждой итерации происходит выборка всей таблицы?

X++:

select firstfast ReturnActionDefaults;

а прогрессбар лучше поменьше обновлять, т.к. он замедляет работу

Eldar9x · 05.03.2009, 11:02

Цитата:

Я его обновляю после каждой затяжки, каждой из строк.

progress.setText(strfmt("Обработано записей: %1", CurrentOperationProgress));

setText не обязательно обновит текст. Надо использовать progress.update(true) после изменения текста.

**mazzy** · 05.03.2009, 11:07

Цитата:

Сообщение от belugin

В аксапте сравнение регистронезависимое. Для регистрозависимого надо использовать strCmp

О! Спасибо, добрый фей. Стало быть я лишний код пишу...

Цитата:

Сообщение от bobski

Все верно, Сергей. Модель восстановления - полная. Серия непрерывная.

проверяйте.

Цитата:

Сообщение от bobski

Ясное дело, что обновляется прогресс бар через определенный промежуток времени. Допустим, что каждую секунду. Стало быть такт = 1сек. Так вот в самом начале процесса загрузки число обработываемых строк за такт около 300. Постепенно, при обновлении прогресс бара число обработанных за такт строк снижается. И к пятой-шестой минуте снижается до позорных 50 за такт. Странно.

А дальше снижается или так и остается 50 за такт?

Цитата:

Сообщение от bobski

Прошу прощения за следущий вопрос: где увеличить инкремент для trnasaction log?

В SQL Server Management Studio

**mazzy** · 05.03.2009, 11:11

Цитата:

Сообщение от Sada

Прогреcc бар сделан для пользователей, чтобы имитировать процесс участия.

Зачастую показывает всякую хрень.

Не...
Прогресс бар дает возможность прервать длительные операции

Без него аксапта неохотно принимает даже Ctrl+Break

Цитата:

Сообщение от ice

а прогрессбар лучше поменьше обновлять, т.к. он замедляет работу

Была ветка про прогесс-бар.
Он хорошо написан. И лишнего не делает.
Время тратится только на вызов методов. Реальная отрисовка делается только раз в секунду на клиенте или раз в три секунды на сервере (если программист не сказал иного при инициализации).

Цитата:

Сообщение от Eldar9x

setText не обязательно обновит текст. Надо использовать progress.update(true) после изменения текста.

А вот это точно замедлит работу.
Хотя для отладки можно и так попробовать.

ZVV · 05.03.2009, 11:15

Цитата:

Сообщение от bobski

Имеется текстовый файл с операциями из другой системы (не Ax), разделитель ";" читаем его используя класс ASCIio, тянем контейнерами построчно.

1. Может проблема как раз в этом (не уверен)...
Попробуйте сделать просто цикл и 120000 вызовов вашего метода, не читая файлик?
Что-то изменится?

2. Слишком частый коммит, на самом деле, часто тоже вредит производительности, т.к. при каждом его выполнении серверу БД нужно выполнить т.н. чекпоинт и т.п. Это тема для отдельного разговора, но суть в том, что это дополнительный оверхед.
Попробуйте делать коммит хотя бы пачками, по 1000 штук например...
Что-то изменится?

Eldar9x · 05.03.2009, 11:28

Цитата:

Попробуйте делать коммит хотя бы пачками, по 1000 штук например...

действительно, я вообще не понимаю зачем создавать для каждой строки транзакцию.
Если у вас там выше (для общего цикла по файлу) нет общей обрамляющей транзакции, тогда в базе будет каша, часть строк создаться, часть нет.
Я бы вообще сделал в виде:

X++:

ttsbegin;
  
{

}
ttscommit;

и все, больше не надо нигде открывать транзакций, тогда гарантировано, либо создадутся все строки по файлу, либо ничего в базе не поменяется.

Цитата:

А вот это точно замедлит работу.
Хотя для отладки можно и так попробовать.

Ну да. Имелось ввиду не для каждой строки. Например, каждые 500 записей.

bobski · 05.03.2009, 11:36

да, поменяю модель восстановления БД на Простую. Во-вторых сделаю Сжать. Инкремент transaction log поставлю 80 МБ. Транзакции будут закрываться на уровне 1000 записей. Посмотрю на выполнение и скорость снова. Отпишусь.

**mazzy** · 05.03.2009, 11:44

Цитата:

Сообщение от Eldar9x

и все, больше не надо нигде открывать транзакций, тогда гарантировано, либо создадутся все строки по файлу, либо ничего в базе не поменяется.

И будет чертовски обидно, если после нескольких часов работы транзакция откатится из-за недостатка места под transaction log

Не говоря уже о тех несчастных пользователях, которые ждут окончания блокировки чтобы продолжить свою никчемную работу по обработке текущих заказов, а также любых складских операций (из-за блокировки inventSum)

Похожие темы
Тема	Автор	Раздел	Ответов	Посл. сообщение
Расчеты с поставщиками\Функции\Создание на основе заказов\Резервирование заказанной номенклатуры	slava09	DAX: Функционал	10	30.01.2007 13:57
Создание склад. журналов из заказов	basanko	DAX: Функционал	17	30.12.2006 11:49
Создание заказов пакетно	chel	DAX: Администрирование	5	01.07.2004 15:13
"Закупка на основе заказов" или "сводное планирование"	Hamster	DAX: Функционал	2	17.02.2004 01:47
Создание заказа?	2b4fITin	DAX: Функционал	13	02.02.2004 15:52