Имя: Пароль:
1C
1С v8
Разное время записи в регистры
0 prad2002
 
03.09.15
10:31
Всем привет!
Тема создана по мотивам вот этой ветки:
Второй и последующие разы проводит быстрее.

Вкратце: имеется сильно перепиленная УТ10 на SQL. Замечено, что при проведении существующего документа в первый раз строка Движения.Записать() отрабатывает ОЧЕНЬ долго (порядка 30-40 секунд), во второй и последующие разы строка отрабатывает за 0,2-0,3 секунды. Если повторить процедуру на следующий день - та же картина.
В файловом варианте в первый раз записывает тоже долго, но разрыв во времени в 2 раза, а не в 100.
Отключение регламентов на SQL на ситуацию не влияет. Подскажите в какую сторону копать?
1 Живой Ископаемый
 
03.09.15
10:33
второй такой же документ если его проводить в первый раз - тоже долго проводится?
2 koreav
 
03.09.15
10:43
я бы смотрел в таком порядке отладчик-профайлер SQL-железо сервера
3 Лефмихалыч
 
03.09.15
10:46
апдэйт статистики как часто делается?
4 prad2002
 
03.09.15
10:47
(1) Да
(3) Статистика каждую ночь
5 MadJhey
 
03.09.15
10:47
(0) ни в какую.  В первый раз идет расчет планов запросов, заполнение кэша. (2) и что ты там увидишь? Первый раз - план запроса не оптимален, второй и последующие - оптимален. Это и так можно сказать. смирится.
6 Fragster
 
гуру
03.09.15
10:50
(0) изначально документ не проведен, а потом перепроводите уже проведенный?
7 Fragster
 
гуру
03.09.15
10:50
проверьте, что кое-кто не рассчитал итоги на 100 лет вперед
8 prad2002
 
03.09.15
10:51
(6) изначально док проведен, просто перепровожу
(7) итоги пересчитывает раз в неделю
9 prad2002
 
03.09.15
10:56
(5) какое отношение план запроса имеет к строке Движения.Записать()?
10 Fragster
 
гуру
03.09.15
10:57
переписать Движения.Записать() На
Движения.Рег1.Записать();
Движения.Рег2.Записать();
...
и посмотреть, какой регистр долго пишется
11 MadJhey
 
03.09.15
10:58
(7) оно бы тогда всегда тормозило, а не только первый раз. Там еще и кэш 1с заполняется. Если сильно, сильно интересно, то можно запарится. Вначале вычислить на каком этапе тормоза:
1с, SQL. Потом из-за чего: статистика SQL или еще чего. Потом попробовать оставлять старую статистику, если получится то выборочно (Не знаю можно ли так сделать).
12 koreav
 
03.09.15
11:02
(5) что значит "план запроса не оптимален" в контексте записи движений? там запрос на инсерт, и все элементарно

Еще можно увидеть в том же профайлере использование процессора, диска и прочего. Возможно таблица была не в оперативке СКЛ?
2)РЛС?
3)модуль набора записей?
4)если провести(30с),перепровести(0,2с),распровести и провести заново(тут сколько?)
13 Fragster
 
гуру
03.09.15
11:02
кстати, в 8.3 было кое что оптимизировано по поводу записи регистров, у автора какая платформа?
14 MadJhey
 
03.09.15
11:02
(9) вот ты сейчас фигню написал. Любое действие c данными в 1с делается через запросы.
15 prad2002
 
03.09.15
11:07
(13) 8.2.19.80
16 Fragster
 
гуру
03.09.15
11:08
(15) переходите на 8.3.6.2100
17 Fragster
 
гуру
03.09.15
11:09
(16) + и реструктуризацию после перехода
18 prad2002
 
03.09.15
14:05
SQL профайлером мониторил событие RPC:completed. Нашел, что в первый раз команда delete и insert  в один из самописных регистров сведений идет крайне долго. Второй раз те же команды выполняются мгновенно.
Ковыряю структуру регистра, индексы, общий размер.