Вход | Регистрация


1С:Предприятие :: 1С:Предприятие 8 общая

УТ 11.4 медленно заполняется регистр сведений СуммыДокументовВВалютеРегл

УТ 11.4 медленно заполняется регистр сведений СуммыДокументовВВалютеРегл
Я
   jk3
 
18.07.18 - 12:54
Обновил УТ с 11.3 до 11.4.
Очень медленно идёт дозаполнение регистра сведений СуммыДокументовВВалютеРегл
Процедура "РегистрыСведений.СуммыДокументовВВалютеРегл.ОбработатьДанныеДляПереходаНаНовуюВерсию" обработки данных в данный момент выполняется.
Заполняет новые ресурсы "СуммаБезНДСУпр", "СуммаНДСУпр" и "БазаНДСУпр". Для рублевых документов добавляет записи.


Заполнило за сутки 800 тыс. записей, а всего их 1,6 млн должно быть (по данным тестовой базы).

Как-то можно ускорить заполнение регистра?

Попробовать перестроить кластерный индекс этой таблицы в MS SQL.
Такое ощущение, что стало только хуже.
Скорость около 10 записей в секунду.

Такими темпами будет выполняться еще 22 часа, если непрерывно, по факту еще дольше будет.
 
 
   RomanYS
 
1 - 18.07.18 - 12:59
Посмотреть что  в РегистрыСведений.СуммыДокументовВВалютеРегл.ОбработатьДанныеДляПереходаНаНовуюВерсию. Сделать замеры.
Может там обработчики какие ненужные отрабатывают или Записать() в цикле по записям.
   Новиков
 
2 - 18.07.18 - 13:20
А у тебя запускаются фоновые задания Выполняется распределение расчетов с клиентами? Если да, попробуй их отключить.
   jk3
 
3 - 18.07.18 - 13:47
(2) В списке фоновых заданий к регламентным относится только "Отложенное обновление ИБ"

Остальные фоновые задания от нормальной работы юзеров в базе:
- Выполнение отчета: РасчетыСКлиентами
- Выполнение отчета: ВыручкаИСебестоимостьПродаж
- Поиск в динамическом списке: Справочник.Партнеры.Форма.ФормаСпискаБезПолнотекстовогоПоиска.Список
и т.п.

В течение дня, пока юзеры работают в базе, переключатель Приоритет работы пользователей.
В нерабочее время -- Обработка данных.

Уже отредактировал расписание регламентного задания "Отложенное обновление ИБ".
Было по умолчанию "каждый день; каждые 60 секунд, повторять после завершения через 60 секунд".
Поставил "каждый день; каждые 60 секунд, повторять после завершения через 15 секунд".

Но это не сильно помогает, т.к. запись в таблицу медленная. Кластерный индекс из 7-ми полей -- это нечто.
   jk3
 
4 - 19.07.18 - 08:57
Вчера вечером остановил регламентные задания.
Сделал перестроение индексов всех таблиц базы средствами SQL.
Перезапустил службу 1С.
Включил обратно фоновую обработку.
Итого за ночь стало 1,1 млн записей в этом регистре.
Т.е. обработалось всего 300 тыс. записей.
Мрак.

Кто переводил на 11.4 более-менее большие базы (от 30 ГБ), у всех такая проблема с этим регистром?
   yzimin
 
5 - 19.07.18 - 09:06
Какие характеристики сервера 1С и SQL?

Тоже скоро предстоит переход на 11.4...
   jk3
 
6 - 19.07.18 - 09:46
(5)
Виртуализированная среда Hyper-V.

1C:
v. 8.3.10.2466 x64
Win 2012 R2 Standard x64
32 ГБ ОЗУ
6 ядер 2,2 Ггц

SQL:
MS SQL 2014 (v. 12.0.2000)
Win 2012 R2 Standard x64
32 ГБ ОЗУ
6 ядер 2,2 Ггц
службе SQL выделено 27 ГБ

сеть 1 Гбит между серверами

На сервере 1С так же, кроме служб 1С больше ничего нет.
В настройках кластера выставлен приоритет по производительности.
Допустимый объем памяти кластера 24 ГБ, используется рабочим процессом УТ обычно 3-10 ГБ.
Количество ИБ на процесс = 1.
Кол-во соединений на процесс = 128.
Использование ЦБ в рабочее время + фоновая обработка = до 33% общая загрузка; каждое ядро загружено меньше, чем на 50%; 100% максимальной частоты
Размер базы 43 ГБ без логов, файлы-вложения лежат на отдельном томе.

SQL-сервер больше ничем не занят, обслуживает только сервер 1С.
В мониторе ресурсов ОС:
- использование сети 5-40 МБит/с;
- дисковый ввод-вывод до 4 МБ/сек;
- длина очереди диска = около нуля
- загрузка ЦБ = до 55% общая загрузка; ни одно ядро не загружено на 100%, максимум 1 из ядер до 90% в пиках; 100% максимальной частоты

В мониторе активности SQL по совокупному времени ожидания на 1-ом месте категория ожидания = Latch.
Может кто-нибудь подскажет что это и как это оптимизировать?
   ildary
 
7 - 19.07.18 - 10:04
(6) Сначала засовываем 1С в виртуалку, а потом начинаем сокрушаться что тормозит.
   jk3
 
8 - 19.07.18 - 10:14
(7) Полностью виртуализованная инфраструктура -- сейчас это стандарт во многих компаниях.
Дело в нюансах настройки.
Я сейчас не вижу бутылочного горлышка, кроме этого Latch на SQL. Что-нибудь знает что это?
   ildary
 
9 - 19.07.18 - 10:55
Именно в этом и проблема - суем что попало в виртуалку, не глядя на практический результат (необьясниемые тормоза), а руководствуясь только "нагрузка низкая" и ""все так делают. А потом начинается метание по форумам.

p.s. Сам лично против виртуалок ничего не имею, но учитывая что на мисте вопросы "почему тормозит виртуалка" всплывают постоянно и постоянно при этом звучит "говорят вируталку можно настроить чтобы она не тормозила, но никто не говорит как" - решил держаться от виртуалок подальше.

p.s.s. А насчёт стандарта - а что первичнее в компании - скорость работы сервиса для пользователей или удобство сис.админа? Обычно сис.админы с умным лицом делают как им удобно и потом оттопырив губу презрительно говорят "я все сделал верно, это ваша 1С кривая и тормозит".
   jk3
 
10 - 19.07.18 - 12:44
А как облачные сервисы работают, когда вся база 1С в облаке?
Уж там точно всё виртуальное.
Тормозит?
 
 Рекламное место пустует
   ildary
 
11 - 19.07.18 - 13:44
(10) Слава богу, с облачной 1С не работаю, поэтому не в курсе, как у них. Вдобавок если речь идёт про родное облако 1С - то они-то могут позволить себе качественный тюнинг виртуалки, который обычные конторы скорей всего не делают.
   H A D G E H O G s
 
12 - 19.07.18 - 13:51
(10) План запроса хоть бы собрали.
Вдруг у вас там вообще кластерного индекса нет.
   SergeyKB
 
13 - 19.07.18 - 13:57
(4)
Да регистр кошмарный.. заполнялся несколько дней (база > 200 ГБ)
Проблема в том, что там в один поток пишется по записи
это нужно распараллеливать, чего не хотят делать писатели типовых
насколько помню логика этого регистра это работа с данными от документа, что прекрасно может распаралеллиться в несколько потоков
Более того, он ещё в таблицу изменений регистра пишет несколько часов, документы для последующей обработки
   jk3
 
14 - 19.07.18 - 14:48
(13) Спасибо за комментарий.
Сейчас выставил приоритет "Обработка данных".
Самое интересное, что юзеры ничего не почувствовали по сравнению с приоритетом "Работа пользователей".
Говорят, как тормозило, так и тормозит =)
   jk3
 
15 - 19.07.18 - 14:51
А насчет распараллеливания.
В типовой БП 3.0.61.47 запилили Новый объект: Константа.КоличествоПотоковОбновленияИнформационнойБазы

У УТ в какой-то из следующих версий (>11.4.3.115) это уже добавили?

Хотя бы несколько регистров могли бы параллельно заполняться, а так последовательно то один обрабатывается, то другой.
   SergeyKB
 
16 - 19.07.18 - 15:04
(15)
>Хотя бы несколько регистров могли бы параллельно заполняться

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

но чтобы одно задание, не видел чтобы параллелилось (из тех что висели днями, при обновлениях), хотя может плохо смотрел
   H A D G E H O G s
 
17 - 19.07.18 - 15:07
(5) Виртуалки на одной физ машине запущены?
   jk3
 
18 - 19.07.18 - 15:10
(17) Ща спрошу у админа. К настройкам Hyper-V у меня нет доступа.
   H A D G E H O G s
 
19 - 19.07.18 - 15:14
Latches (Кратковременные блокировки) — статистика по этому специальному типу блокировок. Кратковременные блокировки — это аналоги блокировок, которые налагаются на ресурсы баз данных во избежание проблем. Но кратковременные блокировки налагаются не на страницы в базе данных, а на специальные области в оперативной памяти (например, которые используются для организации страниц в буфере). В основном используется значение счетчика Latch Waits/Sec (Количество ожиданий на установку кратковременных блокировок). Слишком большое значение этого счетчика может говорить о недостатке оперативной памяти для SQL Server;
   H A D G E H O G s
 
20 - 19.07.18 - 15:17
Есть же понимание, что 10 записей в секунду - это дичь дикая?
Я бы поставил на то, что у вас индекс не используется при записи. Либо по его отсутствию, либо по отсутствию статистики. Либо включен параллелизм.
   jk3
 
21 - 19.07.18 - 15:56
(17) Админ сказал "1с и sql на 1 гипервизоре".
   H A D G E H O G s
 
22 - 19.07.18 - 16:06
(21) Как говорил один персонаж...
https://youtu.be/6wRqRjVRx3U
   H A D G E H O G s
 
23 - 19.07.18 - 16:11
Я могу подключиться, посмотреть, при условии

1) Запущен ms sql profiler
2) Запущен ms enterprise manager
3) Запущен конфигуратор с точкой останова в месте запищи набора регистра.
   jk3
 
24 - 19.07.18 - 16:18
(20) Там дичь коде РегистрСведений.СуммыДокументовВВалютеРегл.ОбработатьДанныеДляПереходаНаНовуюВерсию()
Там не просто запись.
Там цикл по видам доков, а их 36 штук.
Внутри цикла сначала выборка данных, потом в цикле запись с предварительными проверками...
   jk3
 
25 - 19.07.18 - 16:19
(20) Да всё там есть у соответствующей таблицы регистра.
Максимальная степень параллелизма = 0
   jk3
 
26 - 19.07.18 - 16:20
(22) Это хорошо или плохо?
   jk3
 
27 - 19.07.18 - 16:20
Имею ввиду что "1с и sql на 1 гипервизоре"
   H A D G E H O G s
 
28 - 19.07.18 - 16:34
(25)
Максимальная степень параллелизма = 0
Это плохо.
Имею ввиду что "1с и sql на 1 гипервизоре"
Это плохо. Это худшее из виртуализации, что можно только сделать.
   H A D G E H O G s
 
29 - 19.07.18 - 16:35
maxdop=1
Сервер 1С и Сервер SQL на одну "ну хотя бы виртуальную машину"
   jk3
 
30 - 19.07.18 - 17:20
(29)
Выставил Max Degree of Parallelism = 1
В плане скорости записи записи в эту таблицу ничего не поменялось.
   jk3
 
31 - 19.07.18 - 17:29
(28) Я, конечно, понимаю, что из-за того, что серверы 1с и sql общаются через tcp/ip и есть какие-то потери в скорости.
Но причём тут виртуализация?
Если бы это были 2 физических сервера соединенных сетью, разве что-то изменилось от этого?
   jk3
 
32 - 19.07.18 - 22:00
Поднастроил SQL-сервер по 2-м статьям с ИТС:
https://its.1c.ru/db/metod8dev#content:5904:hdoc
https://its.1c.ru/db/metod8dev#content:5946:hdoc
Единственное, у базы не стал включать асинхронное автоматическое обновление статистики. Пусть продолжает работать в синхронном режиме.
Перезапустил службу SQL-сервера.

Обработка регистра раз в 5 ускорилась.
   jk3
 
35 - 20.07.18 - 09:18
Итого обработка регистра длилась 73 часа.

А насчет виртуализации, если серверы 1С и SQL разнести на разные гипервизоры, будет лучше?
   H A D G E H O G s
 
36 - 20.07.18 - 11:35
(35) Лучше будет, если 1С и SQL поместить на одну виртуальную машину.
   jk3
 
37 - 20.07.18 - 12:59
(36) Это понятно, чтобы исключить прослойку в виде tcp/ip и организовать обмен сервера 1с и sql только через общую память.
Но масштабировать эту систему можно будет только вертикально, а горизонтально уже не получится.
   jk3
 
38 - 20.07.18 - 13:00
Кстати, после всех настроек SQL категория ожидания Latch стала почти 0.
Зато на 1-е место вышла категория ожидания Buffer I/O.
   H A D G E H O G s
 
39 - 20.07.18 - 13:15
(37) У вас она и так на одном гипервизоре.
   H A D G E H O G s
 
40 - 20.07.18 - 13:15
(38) Ради интереса, верни maxdop=0 и перезагрузи sql и посмотри latch
   jk3
 
41 - 23.07.18 - 09:23
(40) Ради интереса так и сделал.
При maxdop=0 опять Latch выходит на 1-е место по колонке Совокупное время ожидания (в секундах).

Никогда бы не догадался, что эти 2 значения так связаны между собой, т.к. в описании Latch при высоком значении этого счетчика написано о недостатке оперативной памяти.
А оказывается это блокировки, когда параллельно исполняемые планы запросов ждут завершения друг друга.
   H A D G E H O G s
 
42 - 23.07.18 - 10:43
(41) А по скорости?
   jk3
 
43 - 23.07.18 - 15:52
(42) А как замерить?
На отзывы юзеров нельзя полагаться, у них всегда всё медленно =)
   H A D G E H O G s
 
44 - 23.07.18 - 15:57
(43) Ну ты же как то замерял :-)
"Обработка регистра раз в 5 ускорилась."
   H A D G E H O G s
 
45 - 23.07.18 - 15:58
Я понимаю, надо будет базу-копию разворачить, но просто думается мне, что причина была в maxdop. А чтобы точно знать причину - нужно смотреть план запроса на update регистра.
   mr freeman
 
46 - 23.07.18 - 16:19
(45) а что ты хочешь там увидеть, в планах? у тебя были случаи когда выбирались неправильные планы для записи регистров? там же платформа все запросы делает, в соответствии с индексами которые сама же и создает.
   Franchiser
 
47 - 23.07.18 - 16:21
менеджер записи долго работает
   xXeNoNx
 
48 - 23.07.18 - 16:21
(0) а шо показывает sys.dm_os_wait_stats?
   H A D G E H O G s
 
49 - 23.07.18 - 16:22
(46) TableSpool при параллелизме я там могу увидеть.
 
 Рекламное место пустует
   xXeNoNx
 
50 - 23.07.18 - 16:23
а разве пишет не быстрее, если нету индексов?
   H A D G E H O G s
 
51 - 23.07.18 - 16:23
(50) Вот так вы и палитесь.
   mr freeman
 
52 - 23.07.18 - 16:24
(48) написал же в топике, латчи показывает
   xXeNoNx
 
53 - 23.07.18 - 16:24
(51) мы и не так можем
   H A D G E H O G s
 
54 - 23.07.18 - 16:24
(50) Чтобы записать что-то ненужное, надо найти что-то не нужное.
   xXeNoNx
 
55 - 23.07.18 - 16:26
(54) тайный смысл?
   mr freeman
 
56 - 23.07.18 - 16:26
(49) а что плохого в table spool?
   H A D G E H O G s
 
57 - 23.07.18 - 16:28
(56) Действительно, нет ничего плохого в процессе update-а записи, сбросить промежуточный результат во временную таблицу.
   H A D G E H O G s
 
58 - 23.07.18 - 16:28
в (57) - сарказм.
   H A D G E H O G s
 
59 - 23.07.18 - 16:29
(55) Тайный смысл ЧЕГО. Тайный смысл оператора
Where в запросе на Update ?
   xXeNoNx
 
60 - 23.07.18 - 17:47
(59) про where кто-то говорил? Если да, то пардон
   mr freeman
 
61 - 23.07.18 - 18:12
(57) ты путаешь спул и спил
   H A D G E H O G s
 
62 - 23.07.18 - 18:15
(61) Спил? Как это будет в оригинале?
   mr freeman
 
63 - 23.07.18 - 18:25
Operator used tempdb to spill. Это предупреждение такое
   mr freeman
 
64 - 23.07.18 - 18:26
   H A D G E H O G s
 
65 - 23.07.18 - 19:19
   H A D G E H O G s
 
66 - 23.07.18 - 19:23
(65) Насколько я понял из статьи. Оптимизатор SQL, при параллелизме, при nestedloops, вставляет промежуточный результат во временную таблицу, исходя из того, что при работе от холодного кэша, это будет не сильно медленней, чем если бы он не вставлял этот результат. При работе от горячего кэша, результат в 3 раза хуже.

Зачем оптимизатор использует ВТ - не сказано, ВОЗМОЖНО, хранить промежуточный результат при параллельном поиске (это мое предположение) в целях экономии памяти.
   mr freeman
 
67 - 23.07.18 - 21:28
(65) а где там написано что спул может быть причиной ожиданий на латчах? Или это твое предположение которое ты хотел проверить?
   H A D G E H O G s
 
68 - 23.07.18 - 21:29
(67) "Или это твое предположение которое ты хотел проверить?"

Именно.
   mr freeman
 
69 - 23.07.18 - 21:56
(41) >>когда параллельно исполняемые планы запросов ждут завершения друг друга

это CXPACKET, а у тебя латчи, вот в этом-то и прикол
   Лефмихалыч
 
70 - 23.07.18 - 22:08
Я бы в скульную таблицу прямым запросом насовал записей. Просто, чтобы не думать вот это вот всё.

Одноразовая операция, на кой хрен ее думать?..
   mr freeman
 
71 - 23.07.18 - 22:27
(70) а контроль уникальности записей по измерениям кто будет делать?


Список тем форума
Рекламное место пустует  Рекламное место пустует
Глупец, лишенный способности посмеяться над собой вместе с другими, не сможет долго выносить программирование.
Фредерик Брукс-младший
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует