axa 3.0 клинит по страшному

[dim123]

Цитата:

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

Тут еще важно соотношение между этими таблицами,
если количество записей в них примерно совпадает, то оптимизатору нечего делать.
если количество записей в одной отличается в разы/на порядки, то оптимизатор может начать выборку с маленькой таблицы.


Наверное.

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


мысль правильная. Только она поднимет общую производительность, а не данную конкретную задачу.

нормальная рабочая ситуатция
1) в минуту 7 запросов на состояние склада
2) каждые 10 минут регистрация готовой продукции . т.е проверка наличия материалов плюс к этому
у нас рецептура не конкретная . т.е имеем Продукт Н1 . он состоит из компонента К1 и К2. каждые 10 минут принимая Н1 на склад проиходит
а) берем БОМ смотрим компоненты К1 и К2 , далее если компонента имеет подгруппу ПГ1. то берем все материалы с подгруппой ПГ1
находим их текущее количество на складе . Далее создаем журнал где используем вместо К1 все материалы ис подгруппы ПГ1 % их текущему количеству на складе.
3) склад в день принимает до 200 новых партий .
4) по всем складам движение с партией . порядка 200
5) продажи 200 партии

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

все это как мне кажетца и убивает эти таблицы , диски не справляютца . вернее сказать время на чтение и запись .

[ViV]

Цитата:

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

все это как мне кажетца и убивает эти таблицы , диски не справляютца . вернее сказать время на чтение и запись .

Так посмотрите статистику на серверах - хотя бы дисковые очереди и загрузку памяти. Чтобы слова "кажетца" не было.

[dim123]

Цитата:

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

Так посмотрите статистику на серверах - хотя бы дисковые очереди и загрузку памяти. Чтобы слова "кажетца" не было.

disk time 90% - 100%
при все при этом disk IO 2-3 mb/sek

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

в понеделник буду таблицы по раидам распихивать , другой быстрой возможности не наити как мне кажеца

[tolstjak]

Цитата:

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

2 сервера 1 АОС 2 база
15 пользователей
inventtrans 2,5 мил записей
inventdim i inventsum 0,5 мил записей

в минуту примерно 6 раз делаетса запрос на текущее состояние скалда.

В момент когда Буалтер дополнителнио добавляет к Счетам на покупку дополнительные расходы система в определенных местах подвисает на 10 минут . Т.е невозможно взять продукцыю невозможно начать новый заказа на производство .
Не получит состояние склада .

Кто нибудь можете подсказать в чем загвоздка

2 сервера 1 АОС 2 база
более 70 пользователей
inventtrans более 4,0 млн. записей
inventdim 0,057 млн.записей
inventsum 0,26 мил записей

Тормозов особых не наблюдаем.
Если и бывают то только во время массовой разноски документов с проводками по главной книге с большим количеством строк. Ловим с помощью "Блокировки пользователей базы данных", а потом разбираемся конкретно с пользователем, что он в это время делал.

[Vadik]

Цитата:

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

disk time 90% - 100%
при все при этом disk IO 2-3 mb/sek
диски не успевают , изза большого количества обращений. к этим таблицам . индексы изменения и тд

15 пользователей ? не смешно

Цитата:

в понеделник буду таблицы по раидам распихивать , другой быстрой возможности не наити как мне кажеца

Количество физических дисков (шпинделей) от этого увеличится? Если нет - то зачем?
Вариантов масса
- включить трассировку длинных запросов в AX, выйти на проблемный кусок кода, разобраться и устранить
- поставить SQL Server 2005 Performance Dashboard Reports, идентифицировать проблемный запрос, выйти на проблемный кусок кода, разобраться и устранить
- прогнать сессию Database Tuning Advisor, критически посмотреть на результаты его работы и сделать по-своему

[dim123]

Цитата:

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

15 пользователей ? не смешно

Количество физических дисков (шпинделей) от этого увеличится? Если нет - то зачем?
Вариантов масса
- включить трассировку длинных запросов в AX, выйти на проблемный кусок кода, разобраться и устранить
- поставить SQL Server 2005 Performance Dashboard Reports, идентифицировать проблемный запрос, выйти на проблемный кусок кода, разобраться и устранить
- прогнать сессию Database Tuning Advisor, критически посмотреть на результаты его работы и сделать по-своему

увеличица заместо 4 дисков для базы раид 1+0
будет
1) база на 4 дисках раид 1+0
2) таблицы инвентсум на раид 1+0 4 диска
3) инвентдим на раид 1+0 4 диска
4) инвентсум на раид 1+0 4 диска

длинных запросов нету !!!

есть проблемный кусок стандарта . который не хочетца переписывать.

Один раз у нас была проблема с аха 3.0
Ахапта 3.0 и исползование при расчете себестоимости не ФИФО а Среднее за месяц. Ну не работает она не возможно исползовать.
Как не пробуй пересчет занимал до 24 часа когда все висело . Вот

[ZVV]

Цитата:

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

...Ловим с помощью "Блокировки пользователей базы данных"...

Вот-вот...
В первую очередь на это посмотрите!

После беглово прочтения сложилось впечатление, что либо вам удалось по какому-то "суперантипаттерну" настроить всю систему, чтоб тормозило побольше (т.е. проблема не в Аксапте, а с дисками, например), либо банальные блокировки...
Смущает конечно что это стандарт... А стандарт ли в самом деле?

[Wamr]

диски - рейды, хорошо, конечно, но может у вас
ОЗУ мало... 1гиг какой-нибудь или
включен SysDatabaseLog на InventTrans или
сеть между АОС и SQL 10Mb или
но 15 пользователей, чтобы так напрягали систему... очень странно

[Vadik]

Цитата:

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

длинных запросов нету !!!

Вы смотрели или знаете?
Если длинных запросов нет - откуда 90% disk time ?

[dim123]

Цитата:

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

диски - рейды, хорошо, конечно, но может у вас
ОЗУ мало... 1гиг какой-нибудь или
включен SysDatabaseLog на InventTrans или
сеть между АОС и SQL 10Mb или
но 15 пользователей, чтобы так напрягали систему... очень странно

1) 4 giga
2) 1 gig
3) автоматика которая работает через COM

да видно блокировки но а дальше ? 1 делаю журнал инвентеризации , 2 юзер начинает Производство . COM висит
запрос
select t.itemname,s.itemid,sum(s.availphysical) as cnt
from inventsum s, inventdim d, inventtable as t
where s.availphysical<>0 and t.itemid=s.itemid and d.inventlocationid='616' and d.inventdimid = s.inventdimid
and s.dataareaid='hc' and s.itemid like '7%' and d.dataareaid='hc' and t.dataareaid='hc'
group by s.itemid,t.itemname order by s.itemid

висит

[dim123]

Цитата:

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

Вы смотрели или знаете?
Если длинных запросов нет - откуда 90% disk time ?

большое количество запросов

[lev]

Цитата:

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

запрос
select t.itemname,s.itemid,sum(s.availphysical) as cnt
from inventsum s, inventdim d, inventtable as t
where s.availphysical<>0 and t.itemid=s.itemid and d.inventlocationid='616' and d.inventdimid = s.inventdimid
and s.dataareaid='hc' and s.itemid like '7%' and d.dataareaid='hc' and t.dataareaid='hc'
group by s.itemid,t.itemname order by s.itemid

висит

никогда в запросах like бытсро не работал... по крайней мере, сколько раз сталкивался с like, всегда проблема производительности была в нем.

[ZVV]

Цитата:

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

никогда в запросах like бытсро не работал... по крайней мере, сколько раз сталкивался с like, всегда проблема производительности была в нем.

Никогда не говори "никогда"...
Like Lik-у рознь.

[dim123]

Цитата:

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

никогда в запросах like бытсро не работал... по крайней мере, сколько раз сталкивался с like, всегда проблема производительности была в нем.

около 300 миллисек

[Wamr]

топорный метод
from inventsum s (nolock), inventdim d (nolock), inventtable (nolock) as t

[zemlyn]

Цитата:

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

никогда в запросах like бытсро не работал... по крайней мере, сколько раз сталкивался с like, всегда проблема производительности была в нем.

В данном случае сравниваемое значение (строка после like) начинается с "константы", значит индексы могут использоваться. А вот если бы начиналось с %, то да- индексы для этого поля уже не смогли бы использоваться.

[Vadik]

Цитата:

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

висит

Вы уж не обижайтесь, но непонятно пока что ничего
- Начали ветку с добавления накладных расходов на накладную от поставщика, потом переключились на производство и инвентаризацию
- То у Вас disk time 90%, то Lock waits на порядок больше Buffer IO waits (см. первый скриншот)
- Ссылаетесь на использование партий, но в приведенном запросе партии не участвуют, зато присутствуют серийные номера (см. первый скриншот, last expensive queries)
- Чем занимается приложение, ходящее через COM, кем и как написано - непонятно


Начните с простых вещей
- 2 часа на формирование журнала инвентаризации при Ваших объемах - это ненормально. Попробуйте для начала выровнять эту операцию. Например, постройте покрывающий индекс на InventDim по используемым аналитикам (InventDimId, InventLocationId, InventBatchId (?), InventSerialId(?))
- При возникновении блокировки - идентифицируйте оба процесса (блокируемый и блокирующий), по возможности - идентифицируйте выполняющий их функционал

Если этого не сделаете Вы - форумчане за Вас этого не сделают и подавно

P.S. READ_COMMITTED_SNAPSHOT ON включите - что-то изменится ?

[dim123]

Цитата:

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

Вы уж не обижайтесь, но непонятно пока что ничего
- Начали ветку с добавления накладных расходов на накладную от поставщика, потом переключились на производство и инвентаризацию
- То у Вас disk time 90%, то Lock waits на порядок больше Buffer IO waits (см. первый скриншот)
- Ссылаетесь на использование партий, но в приведенном запросе партии не участвуют, зато присутствуют серийные номера (см. первый скриншот, last expensive queries)
- Чем занимается приложение, ходящее через COM, кем и как написано - непонятно


Начните с простых вещей
- 2 часа на формирование журнала инвентаризации при Ваших объемах - это ненормально. Попробуйте для начала выровнять эту операцию. Например, постройте покрывающий индекс на InventDim по используемым аналитикам (InventDimId, InventLocationId, InventBatchId (?), InventSerialId(?))
- При возникновении блокировки - идентифицируйте оба процесса (блокируемый и блокирующий), по возможности - идентифицируйте выполняющий их функционал

Если этого не сделаете Вы - форумчане за Вас этого не сделают и подавно

P.S. READ_COMMITTED_SNAPSHOT ON включите - что-то изменится ?

попытаюсь
1) ахапта 3.0
2) "2 часа на формирование журнала инвентаризации при Ваших объемах - это ненормально"
стандартная логика : у нас 570 000 инвентсум и 2000 инвенттабле . журнала инвентаризации делает 570 000 запросов
3) проблема как я уже написал в 3 таблицах . переписывать стандарт не имеем желания
4) COM - продукция на склад ( Продтабле ) ,движение продуктов ( инвентёурнал ) .

вывод АХАПТА 3.0 стандарт не может внедрятца с исползованием партий ( у нас под партий подразумеваетса гововая продукция EURO поддон с продукцией) . Консултанты не смогли этого предвидеть или не хотели .

РАИД и отказ от партий в ахапте и вынос отделно патрийного учета.


READ_COMMITTED_SNAPSHOT

если инвентсум и транс блокировка na insert form update , manage indeksov . смогу получать даные

[tolstjak]

Цитата:

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

попытаюсь
1) ахапта 3.0
2) "2 часа на формирование журнала инвентаризации при Ваших объемах - это ненормально"
стандартная логика : у нас 570 000 инвентсум и 2000 инвенттабле . журнала инвентаризации делает 570 000 запросов

У нас невозможно выполнять операции с номенклатурой если она входит в созданный журнал инвентаризации. Приходится извращаться.

[ZVV]

Цитата:

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

У нас невозможно выполнять операции с номенклатурой если она входит в созданный журнал инвентаризации. Приходится извращаться.

Вроде как "птичка" специательная есть "Блокировать номенклатуру при инвентаризации" в настройках УЗ...