Цитата:
Сообщение от
trud
Ну вот тут не сходится математика. т.е. у вас 5 заказов в секунду, 90к операций, вы оптимизировали 5 обновлений-вставок 1 записи, и говорите что это как-то заметно должно повлиять?
90k это операций в activity-мониторе. Подозреваю, что это очень большой показатель, который говорит об общей загруженности базы. Т.е. даже если нет блокировок, то такое кол-во запросов довольно тяжело дается серверу. Они грузят процессор (30-40%) и память базы данных. Я вообще убрал запрос, который делал пессимистическую блокировку на основании уникальных аналитик InventSumDelta и вставку-обновление в случае новой одной комбинации. Возможно всему виной таблица InventSumDelta, но у меня там все индексы из R3 + один мой (ItemId, IsAggregated, InventDimId).
Цитата:
Сообщение от
trud
Но ведь параллельные операции InventSum не блокируют, она блокируется в самом конце, т.е. важно сколько параллельных завершений транзакций было и сколько выполнялась проверка остатков в этом завершение транзакции. Вы это замеряли?
Если у вас до 5 позиций, то это проверка должна выполняться мнгновенно и никаких блокировкок быть не должно, ну т.е. вы сами посчитайте, 5 заказов в секунду, наихудший случай, когда в каждом одна и таже аналитика и номенклатура, завершение к примеру идет 100мс (что довольно долго) и то не получается блокировок
НО
В начальных версиях 2012 R3 существовал баг, когда из-за неправильных индексов по InventSumDelta, InventSumDeltaDim эта проверка остатков выбирала неправильный план и выполнялась довольно долго. тогда да, на любой серьезной нагрузке система вставала
Проблема собственно описана
https://axology.wordpress.com/2013/1...umdelta-table/ решением было удаление индексов(всех кроме 1) на указанных таблицах
При расчете нужно не забывать, что есть еще WHSInventReserve, который обновляется по тому же механизму после InventSum и 100мс могут превратиться в нечто большее.
Удалять индексы не стану, но автообновление статистики наверное отключу. Спасибо за статью.