Обновил УТ с 11.3 до 11.4.
Очень медленно идёт дозаполнение регистра сведений СуммыДокументовВВалютеРегл

Процедура "РегистрыСведений.СуммыДокументовВВалютеРегл.ОбработатьДанныеДляПереходаНаНовуюВерсию" обработки данных в данный момент выполняется.
Заполняет новые ресурсы "СуммаБезНДСУпр", "СуммаНДСУпр" и "БазаНДСУпр". Для рублевых документов добавляет записи.


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

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

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

Такими темпами будет выполняться еще 22 часа, если непрерывно, по факту еще дольше будет.

Посмотреть что  в РегистрыСведений.СуммыДокументовВВалютеРегл.ОбработатьДанныеДляПереходаНаНовуюВерсию. Сделать замеры.
Может там обработчики какие ненужные отрабатывают или Записать() в цикле по записям.

А у тебя запускаются фоновые задания Выполняется распределение расчетов с клиентами? Если да, попробуй их отключить.

(2) В списке фоновых заданий к регламентным относится только "Отложенное обновление ИБ"

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

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

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

Но это не сильно помогает, т.к. запись в таблицу медленная. Кластерный индекс из 7-ми полей -- это нечто.

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

Кто переводил на 11.4 более-менее большие базы (от 30 ГБ), у всех такая проблема с этим регистром?

Какие характеристики сервера 1С и SQL?

Тоже скоро предстоит переход на 11.4...

(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.
Может кто-нибудь подскажет что это и как это оптимизировать?

(6) Сначала засовываем 1С в виртуалку, а потом начинаем сокрушаться что тормозит.

(7) Полностью виртуализованная инфраструктура -- сейчас это стандарт во многих компаниях.
Дело в нюансах настройки.
Я сейчас не вижу бутылочного горлышка, кроме этого Latch на SQL. Что-нибудь знает что это?

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

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

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

А как облачные сервисы работают, когда вся база 1С в облаке?
Уж там точно всё виртуальное.
Тормозит?

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

(10) План запроса хоть бы собрали.
Вдруг у вас там вообще кластерного индекса нет.

(4)
Да регистр кошмарный.. заполнялся несколько дней (база > 200 ГБ)
Проблема в том, что там в один поток пишется по записи
это нужно распараллеливать, чего не хотят делать писатели типовых
насколько помню логика этого регистра это работа с данными от документа, что прекрасно может распаралеллиться в несколько потоков
Более того, он ещё в таблицу изменений регистра пишет несколько часов, документы для последующей обработки

(13) Спасибо за комментарий.
Сейчас выставил приоритет "Обработка данных".
Самое интересное, что юзеры ничего не почувствовали по сравнению с приоритетом "Работа пользователей".
Говорят, как тормозило, так и тормозит =)

А насчет распараллеливания.
В типовой БП 3.0.61.47 запилили Новый объект: Константа.КоличествоПотоковОбновленияИнформационнойБазы

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

Хотя бы несколько регистров могли бы параллельно заполняться, а так последовательно то один обрабатывается, то другой.

(15)
>Хотя бы несколько регистров могли бы параллельно заполняться

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

но чтобы одно задание, не видел чтобы параллелилось (из тех что висели днями, при обновлениях), хотя может плохо смотрел

(5) Виртуалки на одной физ машине запущены?

(17) Ща спрошу у админа. К настройкам Hyper-V у меня нет доступа.

Latches (Кратковременные блокировки) — статистика по этому специальному типу блокировок. Кратковременные блокировки — это аналоги блокировок, которые налагаются на ресурсы баз данных во избежание проблем. Но кратковременные блокировки налагаются не на страницы в базе данных, а на специальные области в оперативной памяти (например, которые используются для организации страниц в буфере). В основном используется значение счетчика Latch Waits/Sec (Количество ожиданий на установку кратковременных блокировок). Слишком большое значение этого счетчика может говорить о недостатке оперативной памяти для SQL Server;

Есть же понимание, что 10 записей в секунду - это дичь дикая?
Я бы поставил на то, что у вас индекс не используется при записи. Либо по его отсутствию, либо по отсутствию статистики. Либо включен параллелизм.

(17) Админ сказал "1с и sql на 1 гипервизоре".

(21) Как говорил один персонаж...
https://youtu.be/6wRqRjVRx3U

Я могу подключиться, посмотреть, при условии

1) Запущен ms sql profiler
2) Запущен ms enterprise manager
3) Запущен конфигуратор с точкой останова в месте запищи набора регистра.

(20) Там дичь коде РегистрСведений.СуммыДокументовВВалютеРегл.ОбработатьДанныеДляПереходаНаНовуюВерсию()
Там не просто запись.
Там цикл по видам доков, а их 36 штук.
Внутри цикла сначала выборка данных, потом в цикле запись с предварительными проверками...

(20) Да всё там есть у соответствующей таблицы регистра.
Максимальная степень параллелизма = 0

(22) Это хорошо или плохо?

Имею ввиду что "1с и sql на 1 гипервизоре"

(25)
Максимальная степень параллелизма = 0
Это плохо.

Имею ввиду что "1с и sql на 1 гипервизоре"
Это плохо. Это худшее из виртуализации, что можно только сделать.

maxdop=1
Сервер 1С и Сервер SQL на одну "ну хотя бы виртуальную машину"

(29)
Выставил Max Degree of Parallelism = 1
В плане скорости записи записи в эту таблицу ничего не поменялось.

(28) Я, конечно, понимаю, что из-за того, что серверы 1с и sql общаются через tcp/ip и есть какие-то потери в скорости.
Но причём тут виртуализация?
Если бы это были 2 физических сервера соединенных сетью, разве что-то изменилось от этого?

Поднастроил SQL-сервер по 2-м статьям с ИТС:
https://its.1c.ru/db/metod8dev#content:5904:hdoc
https://its.1c.ru/db/metod8dev#content:5946:hdoc
Единственное, у базы не стал включать асинхронное автоматическое обновление статистики. Пусть продолжает работать в синхронном режиме.
Перезапустил службу SQL-сервера.

Обработка регистра раз в 5 ускорилась.

Итого обработка регистра длилась 73 часа.

А насчет виртуализации, если серверы 1С и SQL разнести на разные гипервизоры, будет лучше?

(35) Лучше будет, если 1С и SQL поместить на одну виртуальную машину.

(36) Это понятно, чтобы исключить прослойку в виде tcp/ip и организовать обмен сервера 1с и sql только через общую память.
Но масштабировать эту систему можно будет только вертикально, а горизонтально уже не получится.

Кстати, после всех настроек SQL категория ожидания Latch стала почти 0.
Зато на 1-е место вышла категория ожидания Buffer I/O.

(37) У вас она и так на одном гипервизоре.

(38) Ради интереса, верни maxdop=0 и перезагрузи sql и посмотри latch

(40) Ради интереса так и сделал.
При maxdop=0 опять Latch выходит на 1-е место по колонке Совокупное время ожидания (в секундах).

Никогда бы не догадался, что эти 2 значения так связаны между собой, т.к. в описании Latch при высоком значении этого счетчика написано о недостатке оперативной памяти.
А оказывается это блокировки, когда параллельно исполняемые планы запросов ждут завершения друг друга.

(41) А по скорости?

(42) А как замерить?
На отзывы юзеров нельзя полагаться, у них всегда всё медленно =)

(43) Ну ты же как то замерял :-)

"Обработка регистра раз в 5 ускорилась."

Я понимаю, надо будет базу-копию разворачить, но просто думается мне, что причина была в maxdop. А чтобы точно знать причину - нужно смотреть план запроса на update регистра.

(45) а что ты хочешь там увидеть, в планах? у тебя были случаи когда выбирались неправильные планы для записи регистров? там же платформа все запросы делает, в соответствии с индексами которые сама же и создает.

менеджер записи долго работает

(0) а шо показывает sys.dm_os_wait_stats?

(46) TableSpool при параллелизме я там могу увидеть.

а разве пишет не быстрее, если нету индексов?

(50) Вот так вы и палитесь.

(48) написал же в топике, латчи показывает

(51) мы и не так можем

(50) Чтобы записать что-то ненужное, надо найти что-то не нужное.

(54) тайный смысл?

(49) а что плохого в table spool?

(56) Действительно, нет ничего плохого в процессе update-а записи, сбросить промежуточный результат во временную таблицу.

в (57) - сарказм.

(55) Тайный смысл ЧЕГО. Тайный смысл оператора
Where в запросе на Update ?

(59) про where кто-то говорил? Если да, то пардон

(57) ты путаешь спул и спил

(61) Спил? Как это будет в оригинале?

Operator used tempdb to spill. Это предупреждение такое

https://prnt.sc/k9z05c

(63) Я не про это

https://www.sqlshack.com/parallel-nested-loop-joins-the-inner-side-of-nested-loop-joins-and-residual-predicates/

(65) Насколько я понял из статьи. Оптимизатор SQL, при параллелизме, при nestedloops, вставляет промежуточный результат во временную таблицу, исходя из того, что при работе от холодного кэша, это будет не сильно медленней, чем если бы он не вставлял этот результат. При работе от горячего кэша, результат в 3 раза хуже.

Зачем оптимизатор использует ВТ - не сказано, ВОЗМОЖНО, хранить промежуточный результат при параллельном поиске (это мое предположение) в целях экономии памяти.

(65) а где там написано что спул может быть причиной ожиданий на латчах? Или это твое предположение которое ты хотел проверить?

(67) "Или это твое предположение которое ты хотел проверить?"

Именно.

(41) >>когда параллельно исполняемые планы запросов ждут завершения друг друга

это CXPACKET, а у тебя латчи, вот в этом-то и прикол

Я бы в скульную таблицу прямым запросом насовал записей. Просто, чтобы не думать вот это вот всё.

Одноразовая операция, на кой хрен ее думать?..

(70) а контроль уникальности записей по измерениям кто будет делать?