![]() |
#1 |
Участник
|
Обработка накладной в заказе больше 10 минут для 200 строк
Здравствуйте.
Вот такая проблема возникла. Обработка накладной в заказе идет больше 10 минут. Количество строк 200. Axapta 3.0 SP3CU1, Application измененный (но мне кажется проблемы не в приложении). Размер БД 14 GB. Две компании. Одна тестовая, полностью дублирует оригинал. запускаю в 2-х уровневой на сервере. Железо:4-х процессорный Intel Xeo 2,4 Ghz, 3GB оперативки. в MSSQL включены все 4 процессора. MSSQL все настройки по умолчанию, как после установки. Сервер не используется, как контроллер доменов. В профайлере кода смотрел. Оттуда неясно, почему так тормозит. Все цифры в пределах допустимого. Сейчас реиндексацию запустил. Не знаю поможет это или нет. |
|
![]() |
#2 |
Участник
|
Помимо профайлера можно посмотреть трассировку операторов sql, отсортировав ее по времени выполнения - тож удобная штука..
|
|
![]() |
#3 |
Участник
|
Re: Обработка накладной в заказе больше 10 минут для 200 строк
Цитата:
Изначально опубликовано sao
В профайлере кода смотрел. Оттуда неясно, почему так тормозит. Все цифры в пределах допустимого. |
|
![]() |
#4 |
Модератор
|
Re: Обработка накладной в заказе больше 10 минут для 200 строк
Цитата:
Изначально опубликовано sao
Размер БД 14 GB. Две компании. Одна тестовая, полностью дублирует оригинал. запускаю в 2-х уровневой на сервере. а sp_updatestats давно запускали? |
|
![]() |
#5 |
Участник
|
Aplication стандартный. 500 строк в заказе.
Проблема разбивается на: 1. Нажимаем на кнопку Обработка в заказе. Ждем..... 2. Когда идет непосредственно сама обработка накладной. Тоже долго долго ждем. Предварительно сделал чистку, а после описанных изменения обновление статистики http://axapta.mazzy.ru/lib/dbgrowthsolution/ Да... Сам диагноз похож на описанный здесь http://forum.mazzy.ru/index.php?showtopic=1790 Попытки поиска и решения: По первой проблеме Мониторинг показал тормоза вот здесь Class SalesTableType\checkSalesQty Код: ... while select salesLine index hint SalesStatusIdx where salesLine.salesId == salesTable.salesId && (salesLine.salesStatus != SalesStatus::Invoiced && salesLine.salesStatus != SalesStatus::Canceled) || (salesLine.SalesDeliverNow < 0) ... Создал кластерный индекс по (SalesID, RecID), добавил в SalesStatusIdx поле SalesDeliverNow . в коде убрал хинт. в профайлере Query Analyzer получилось около 400 милисекунд. в аксапте менюшка открывается с задержкой 2 - 4 секунды. Можно ли еще что нибудь сделать? Если да, то что? Вообще к чему стремится надо? По второй проблеме Мониторинг показал, что по таким таблицам SalesParmLine, CustInoviceTrans, TaxTrans, LedgerBalancesDimTrans не оптимально выборка проходит. По той же схеме провел оптимизацию. В профайлере кода получил картинку (прилагается). Там динамически запрос создается. Вроде по SalesParmtable, SalesParmLine. особо не разбирался, но может кто подскажет, что можно сделать..? еще тормоза наблюдаютя в Tax\adjustAmount.... В итоге обработка 500 строк получилась около 5 минут. это нормально? Еще вопрос: Почему у многих таблиц нет Primary key и кластерных индексов в стандартном функционале? Последний раз редактировалось sao; 05.02.2007 в 18:26. |
|
![]() |
#6 |
Модератор
|
По первой проблеме - присмотритесь к условию на SalesDeliveryNow - это не проблема с производительностью, это бага, какая-то добрая душа сэкономила пару скобок
PHP код:
![]() |
|
|
За это сообщение автора поблагодарили: kashperuk (2). |
![]() |
#7 |
Banned
|
По-моему, это довольно известных кусок кода. Когда-то боролся. Там ведь, кажется, просто пары скобок после && не хватает? Ограничение по SalesId должно ведь всегда работать.
|
|
![]() |
#8 |
Участник
|
Цитата:
Изначально опубликовано sao
Еще вопрос: Почему у многих таблиц нет Primary key и кластерных индексов в стандартном функционале? Primary key - это ограничение (constraint), которое гарантирует, что набор значений столбцов, входящих в него, будет уникальным в таблице. При этом он также требует, чтобы эти значения были определены, т.е. IS NOT NULL. Кроме того, существует еще одно ограничение, требующее уникальности - UNIQUE. Но при этом значения стобцов могут быть не определены (IS NULL). И как-раз таки это ограничение всегда присутствует в таблице, даже если не создавать индексы. В этом случае создается уникальный индекс на основе поля RecId (и DataAreaId, если таблица разбивается для компаний. Точнее порядок полей в индексе - DataAreaId, RecId). Если же существуют только неуникальные индексы в таблице, то тогда к первому из них так же добавляется поле RecId и индекс объявляется уникальным (правда увидеть это можно только на сервере БД) Таким образом ограничение на уникальность всегда присутствует в таблице в виде Primary Key или Unique Index. По поводу кластерного индекса Использовать его или нет в таблице во многом зависит от характера данных, хранящихся в таблице. Дело в том, что кластерный индекс объединяется с данными. При этом записи на страницах строго упорядочиваются в соответствии с полями, входящими в него. При поиске по ключу кластерного индекса фактически сразу получаем необходимые данные Остальные индексы для таблицы могут ссылаться на данные двумя способами - либо ч/з Row ID если нет кластерного индекса, либо ч/з кластерный индекс в противоположном случае. Большой размер ключа кластерного индекса будет вести к увеличению размера остальных индексов, что ведет в конечном итоге к уменьшению производительности б/д. Т.е. использование/неиспользование кластерных ключей - вопрос поиска компромиссов, результаты которых мы видим в Axapte
__________________
Axapta v.3.0 sp5 kr2 |
|
![]() |
#9 |
Участник
|
Большое спасибо насчет первой проблемы. Сейчас все работает, как надо. А вот вторая без изменений. Допишу еще немного:
Основная валюта RUR, а заказы идут в UE. Из-за этого вызывается Tax\AdjustAmount и теряется около 2 - 3 минут (500 строк в заказе). Само обновление идет около 3 минут. После обновления теряем около 1,3 минуты на SalesFormletter_Invoice\WriteTaxAmount_Ru. Сейчас вопрос стоит можно ли вообще что нибудь придумать, чтоб это стало работать побыстрее? |
|
![]() |
#10 |
----------------
|
Кое-что можно..
PHP код:
Кстати, вспомнил - http://www.axforum.info/forums/showt...t=adjustAmount Еще вспомнил - аналогичные проблемы у приходных накладных. Последний раз редактировалось Wamr; 17.10.2005 в 10:52. |
|
|
За это сообщение автора поблагодарили: raz (6), Logger (10). |
![]() |
#11 |
Шаман форума
|
Цитата:
Сообщение от Wamr
Еще вспомнил - аналогичные проблемы у приходных накладных.
|
|
![]() |
#12 |
Участник
|
Спасибо большое за исправления в налогах. Вообщем стало около 7 - 8 минут для 500 строк. Раньше было 12 - 14. Клиент все равно не доволен
![]() ................ Еще могу добавить, что будет влиять (но не сильно) на производительность галочка Проверка кредитного лимита у клиента. |
|
![]() |
#13 |
Member
|
Цитата:
Сообщение от sao
...
люди сидят до 10:00 и начинают из-за этого увольняться. ... Что вы имеете против такого решения (см. первые полдюжины сообщений)? http://www.axforum.info/forums/showt...1267#post31267
__________________
С уважением, glibs® |
|
![]() |
#14 |
Участник
|
У меня на клиенте после запуска периодического сопоставления в бухгалтерии скорость обработки накладных по закупкам/заказам уменьшается на порядки. Просто 1С какой то.
![]()
__________________
![]() |
|
![]() |
#15 |
Шаман форума
|
Цитата:
Сообщение от ppson
У меня на клиенте после запуска периодического сопоставления в бухгалтерии скорость обработки накладных по закупкам/заказам уменьшается на порядки. Просто 1С какой то.
![]() |
|
![]() |
#16 |
Участник
|
Цитата:
Сообщение от ppson
У меня на клиенте после запуска периодического сопоставления в бухгалтерии скорость обработки накладных по закупкам/заказам уменьшается на порядки. Просто 1С какой то.
![]() ![]() 2. Слушайте что komar говорит. |
|
![]() |
#17 |
Участник
|
Цитата:
Сообщение от komar
В пакетную обработку все! И на ночь - чтобы никто не видел!
Обработку копают, но все как то неприятно.
__________________
![]() |
|
![]() |
#18 |
Модератор
|
Групповая обработка накладных
Далал все сам. Пользователей не устраивает, что что-то там автоматом разносится, и не понятно, что чем закончилось. Короче, свой пакет есть. И форма, в которой видны все добавленные в пакет накладные. Можно выбрать накладные как без комплектации (белый цвет), так и скомплектованные (зеленый цвет).
Вверху видны все накладные, можно убрать фильтр и будет видно как проведенные накладные (желтый цвет), так и удаленные (сторнированные, красный цвет). Эти категории добавить в обработку нельзя. Также видны лапки - статус закупки для этого заказа (специфика) Внизу видны выбранные накладные. Белая лапка - добавлено в обработку, зеленая - обработана, не ошибок, красная - обработана, есть ошибки. Ошибки видны в одном окне, но есть и стнандартный системый журнал. Возможно проставлять дату, которой будет проведена накладная. [IMG]InvoiceBatch2.jpg[/IMG] С Уважением, Георгий |
|
![]() |
#19 |
Moderator
|
Цитата:
Обработку копают, но все как то неприятно.
Но как показывает практика, лучше начать со всяких дописок и своих собственных приблуд ... |
|
![]() |
#20 |
Участник
|
Цитата:
Сообщение от ppson
Не поможет. Отгрузки ведутся круглосуточно.
Обработку копают, но все как то неприятно. Чтобы длительных блокировок не было. Но это, как правило, сильно усложняет алгоритм и защиту от дурака. В общем, читайте чего советуют при работе с базой данных. |
|
Теги |
программно, производительность, ax3.0 |
|
![]() |
||||
Тема | Ответов | |||
Номер и дата накладной в Заказе | 1 | |||
Обработка накладной – функция изменить дату | 2 | |||
Обработка Накладной в Евро | 4 | |||
Суммарная обработка накладной | 1 | |||
Обработка накладной | 1 |
Опции темы | Поиск в этой теме |
Опции просмотра | |
|