Тормозит операция комплектации и не только

[Wamr_imported]

Несколько несформированых мыслей:

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

[Vadik]

Цитата:

Сообщение от =A=L=X=

В конфигурации включены аналитики: Склад, Номер партии, Ячейка, Код палеты, Цвет.

Во время резервирования из-за блокировок таблиц InventDim / InventSum и пр. колом встаёт служба сервиса и менеджеры по закупкам - ни заказы ни закупки не разносятся.

С такими аналитиками на InventDim нет подходящих индексов. Можно начать например с создания подходящего (или правки существующего) на InventDim. Первый на мой взгляд кандидат на это - DimIdx. Перенесите в его начало те аналитики, которые используете - Склад, Ячейку и т.д.

С блокированием InventSum пока не все понятно. "Множественные складские транзакции" используете? Посмотрите на индекс ClosedItemDiomIdx - совершенно дурацкий, как мне кажется (включать ли в индекс поля, принимающие всего два значения 0 и 1 - это отдельный вопрос, но делать их первыми в индексе - это что-то с чем-то). Перенесите в начало ItemId

Сразу оговорюсь - решения самые общие, принесут ли они счастье в Вашем конкретном случае, не видя приложения и БД, сказать нельзя. Но идея простая: чем выше селективность у используемого индекса, тем меньше строк данных и диапазонов индексов будет блокироваться при select forupdate, запущенном одним пользователем, тем комфортнее будет остальным.

[Sergik]

Цитата:

Сообщение от =A=L=X=

Отгрузка из 50-ти позиций резервируется от 2-3 до 30-ти минут! 

Да уж феноменально плохо. У нас к примеру резервируется в течение минуты заказ с 900 - 1000 строками в среднем. Может действительно вам помощь экспертов извне заказать, ну не может же нормально компания работать при таких показателях производительности.

Характеристики оборудования нормальные - здесь проблем нет действительно.

[Alks]

Цитата:

Сообщение от serge kotov

Да уж феноменально плохо. У нас к примеру резервируется в течение минуты заказ с 900 - 1000 строками в среднем. Может действительно вам помощь экспертов извне заказать, ну не может же нормально компания работать при таких показателях производительности.

Характеристики оборудования нормальные - здесь проблем нет действительно.

А сколько у вас складских аналитик включено?

[Alks]

Цитата:

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

Несколько несформированых мыслей:

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

Специалиста за деньги взять негде.
full-scan-ы в заблокированных процессах не объясняют тормознутость блокирующего, который судя по тому что тут говорят
Блокируются вполне тривиальные вещи на обновление - то страницы индексов, то страницы данных таких таблиц как WMSJournalTable, WMSOrderTrans и даже InventTrans и InventDim! 3-4 заблокированных процесса в среднем (как раз те люди, которые пытаются создавать заказы или закупки в текущий момент).

[Alks]

Цитата:

С такими аналитиками на InventDim нет подходящих индексов. Можно начать например с создания подходящего (или правки существующего) на InventDim. Первый на мой взгляд кандидат на это - DimIdx. Перенесите в его начало те аналитики, которые используете - Склад, Ячейку и т.д.
С блокированием InventSum пока не все понятно. "Множественные складские транзакции" используете? Посмотрите на индекс ClosedItemDiomIdx - совершенно дурацкий, как мне кажется (включать ли в индекс поля, принимающие всего два значения 0 и 1 - это отдельный вопрос, но делать их первыми в индексе - это что-то с чем-то). Перенесите в начало ItemId

Спасибо за совет. Не помогло ни капельки.

Множественные складские транзакции включили недели полторы назад.

Цитата:

Но идея простая: чем выше селективность у используемого индекса, тем меньше строк данных и диапазонов индексов будет блокироваться при select forupdate, запущенном одним пользователем, тем комфортнее будет остальным.

Проблемы 2 - ужасная медленность всех этапов обработки заказа и блокировки, возникающие по ходу этого процесса. Проблемы эти взаимоисключающие, ибо если бы быстро разносилось, то и блокировки быстро исчезали бы. Но мы даже разбивая отгрузки на порции по 50 строк не можем обеспечить приличную скорость! Ужас, товарищи.
Ума не приложу где может быть "слабое звено" и как найти где оно может быть. Вполне возможно что это всё таки какая то наша модификация так ужасно работает, но честное слово не могу понять какая, тем более что глубоко в аксапту мы как я уже говорил не залазили.

[Sergik]

Цитата:

Сообщение от =A=L=X=

А сколько у вас складских аналитик включено?

Специалиста за деньги взять негде.

Складских четыре.

ИМХО Стоимость специалиста - эксперта несопоставима с предполагаемой стоимостью потерь бизнеса с учетом того, что он в данном случае потребуется на одну задачу. Главное имеет смысл заодно и поучиться, т.к. вероятно это у вас не единственная проблема.

[mazzy]

Цитата:

Сообщение от =A=L=X=

Специалиста за деньги взять негде.

Специалистов по производительности много.
И предложений тоже.

Вот, например, (Извините. Воспользуюсь служебным положением)
http://performance.rabota-na-rezultat.ru/

Или сделайте поиск. Вы наверняка найдете.

[Alks]

Цитата:

Сообщение от serge kotov

Цитата:

Сообщение от =A=L=X=

А сколько у вас складских аналитик включено?

Специалиста за деньги взять негде.

Складских четыре.

ИМХО Стоимость специалиста - эксперта несопоставима с предполагаемой стоимостью потерь бизнеса с учетом того, что он в данном случае потребуется на одну задачу. Главное имеет смысл заодно и поучиться, т.к. вероятно это у вас не единственная проблема.

Согласен - если дело зайдёт в окончательный тупик другого выхода не будет.
Но и я далеко не "рядовой пользователь" чтобы мирится с таким положением вещей ожидая пока приедет добрый дядя "специалист"...

Самое странное что слабых мест не видно во всей этой белиберде... Ей богу все серваки и клиенты не используют ресурсов своих в сумме и по отдельности больше чем на 50%... Такого, имхо, быть не может.

[Sergik]

Как раз так и бывает при блокировках...

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

ЗЫ Пожалей бедных юзеров, они у вас похоже очень терпеливые, но всему есть предел

[Vadik]

Цитата:

Сообщение от =A=L=X=

Спасибо за совет. Не помогло ни капельки. 

Звиняйте



Это пока все, чем можем помочь в таком режиме общения (вопрос-ответ), не видя приложения и данных. То есть я могу еще повоспроизводить Вашу ситуацию на своей БД (сейчас порядка 25Гб данных), но результаты, боюсь, будут те же самые - ТАКИХ проблем нет

[Alks]

Цитата:

Сообщение от serge kotov

Как раз так и бывает при блокировках...

Не, это происходит и без блокировок, даже когда один пользователь монопольно сидит в базе - тормозит.

[Alks]

Цитата:

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

Цитата:

Это пока все, чем можем помочь в таком режиме общения (вопрос-ответ), не видя приложения и данных. То есть я могу еще повоспроизводить Вашу ситуацию на своей БД (сейчас порядка 25Гб данных), но результаты, боюсь, будут те же самые - ТАКИХ проблем нет

Я понимаю, в любом случае спасибо.

[Alks]

Похоже разобрались в чём дело...

В нашей системе по ряду причин было создано некоторое кол-во "виртуальных" паллет на каждой из которых в сумме находилось более 100 разных видов ном-р (строк в InventSum/проводках и т.п.). Так вот, жутко тормозила операция резервирования именно по тем позициям, которые учавствовали в таких паллетах. По наитию мы сделали кучу переносов, которые разбили такие паллеты на большое число паллет с меньшим кол-вом на каждой и теперь операция резервирования 500 строк занимает порядка 2-х минут, в то время как раньше 50 строк могли резервироваться полчаса.

При этом нами были выполнены все предложенные тут рекомендации - вплоть до полной трассировки SQL-запросов во время операции комплектации. Был получен, например, следующий результат: для одной отдельно взятой строчки отгрузки при резервировании выполнялось 400 запросов. У подавляющего числа этих запросов время выполнения составляло 2 мс. Примерно У трети - 3 мс. И примерно у 20 запросов время было больше 3 мс, но не превышало 20 мс! Полный анализ всех видов из этих запросов показал что у всех у большей части их оптимальный план выполнения (да и куда уж меньше 2-3 мс то можно выполнятся то??), а кол-во не совсем оптимальных запросов не влияет существенно на время выполнения общей процедуры. Другими словами оптимизировать было просто нечего - запросы выполнялись быстро, тормоза возникали из за дикого их количества... Тем более, что "проблемные" номенклатуры могли иметь число запросов еще больше чем 400 и гораздо, а некоторые вообще приводили к deadlock-ам резервирующего процесса с... самим собой! (про это я писал на axforum)

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

Может есть какие нибудь мысли и/или комментарии по этому поводу?

P.S.

Кстати, один fullscan, который возник по нашей вине я всё таки нашел. Неаккуратно в прайс-лист внедрили два поля, но это в другом месте сказывалось.

[mazzy]

Цитата:

Сообщение от =A=L=X=

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

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

[Alks]

Я просто хотел подытожить, что в Аксапте резервирование товара из одной паллеты загруженной 1000-ью номенклатур выполняется в десятки, если не сотни раз медленнее чем резервирование товара из 100-та паллет по 10 ном-р на каждой. (по крайней мере у нас сложилось такое стойкое ощущение)
Оптимизация запросов тут ни при чём - тормоза по видимому сидят в самом алгоритме резервирования, который каким то нехарактерным образом делает селекты по аналитике "паллета".
Разбираться самому сейчас в тонкостях алгоритма резервирования некогда, поэтому полюбопытсвовал - может кто знает почему так...

[SimPai]

Цитата:

разбивать заказы с большими количествами строк на меньшие

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