Имя: Пароль:
1C
1С v8
Непонятные проблемы с производительностью базы на MS SQL
0 GrayT
 
17.05.17
11:24
Есть тестовая база на MS SQL. Работает единственный пользователь, фоновые задачи отключены.
Есть внешняя обработка. При первом выполнении команды расчета производится считывание набора записей непериодического независимого регистра сведений - набор неких показателей. Часть показателей зависят от других. Делаем расчет всех показателей, и производится обратная запись в регистр. На все уходит порядка минуты, полторы.
При повторном выполнении этой же самой команды (такие же параметры расчета) происходит зависание выполнения запроса примерно на час!!!
После этого все повторяется - первый расчет проходит нормально, последующий зависает.
Пытаюсь профайлером определить суть проблемы, но нормально им пользоваться пока не умею и соответственно ни чего не вижу :(
Куда рыть?
1 Ёпрст
 
17.05.17
11:30
Ого, привет Тамбов!
2 Ёпрст
 
17.05.17
11:33
зависает на чем хоть ? На расчете показателей или при записи набора движения в регистр ?
3 GrayT
 
17.05.17
11:38
Строго на запросе. Пакетный запрос.
4 GrayT
 
17.05.17
11:39
Последующий расчет и запись набора проходит без проблем. И результат правильный. Только долгий :)
5 Сергиус
 
17.05.17
11:43
(0)Как настроено выделение памяти для SQL и сколько собственно ее выделено?
6 Вафель
 
17.05.17
11:43
может потому что при 2м расчете идет ПЕРЕзапись набора?
7 Dotoshin
 
17.05.17
11:45
(0) Вот тут посмотри куда рыть https://youtu.be/cSTYlitD8GM
8 GrayT
 
17.05.17
11:54
(5)Может не совсем понял суть вопроса. На виртуальном сервере (тестовый) до 10Г, на реальном до 40Г оперативки. Монитор ресурсов говорит что память есть.
(6)Может, только моих знаний по блокировкам не хватает что бы объяснить происходящее.
9 Вафель
 
17.05.17
11:55
настрой профайлер на долгие запросы
10 МихаилМ
 
17.05.17
12:10
возможно при записи набора данных
у скл сервер что-то слетает типа статистики.
и он не может строить эффективный план запроса.

помогало разовое чтение таблицы в пределах измененных данных + обычно читаемых  (было достаточно быстро).

т.е. после записи прочитайте их из бд.
11 Сергиус
 
17.05.17
14:26
(8)Имелось ввиду на самом SQL server какие настройки по использованию памяти. Может там какое-то ограничение стоит
12 GrayT
 
17.05.17
16:13
Судя по всему тупит оптимизатор запросов. План запросов принципиально разный. И в обоих случаях не оптимальный. Причем при повторном вызове не оптимальный фатально.
И еще - при вызове этого запроса из консоли первый план запроса равен тому что получается из обработки при первом проходе, а при последующих вызовах, получается вообще третий план запроса - самый быстрый (хотя тоже не оптимальный).
Почему так происходит - не понял. То что сильно поверхностно читал статьи по оптимизации - понял. Пошел переписывать запрос и искать вменяемую статью по борьбе со всякими Nested Loops и Index Scan и прочее...
13 Вафель
 
17.05.17
16:16
кстати в там в регистре расчетов не хватает кластерного индекса на какой то таблице
Требовать и эффективности, и гибкости от одной и той же программы — все равно, что искать очаровательную и скромную жену... по-видимому, нам следует остановиться на чем-то одном из двух. Фредерик Брукс-младший