|
Разное время записи в регистры | ☑ | ||
---|---|---|---|---|
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 в один из самописных регистров сведений идет крайне долго. Второй раз те же команды выполняются мгновенно.
Ковыряю структуру регистра, индексы, общий размер. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |