Настройка параметров ibcmd в режиме replicate, а так же СУБД транслятора и СУБД приёмника для оптимальной скорости

Казалось бы, миграция базы 1С с помощью ibcmd и так происходит очень быстро, гораздо быстрее чем выгрузка/загрузка dt.
Но даже эту скорость можно существенно повысить и дальше расскажу как.

Начнём с настроек параметров ibcmd в режиме replicate при сценарии миграции базы с MS SQL на PostgreSQL как самом распространённом:

▫️ Количество потоков чтения (--jobs-count) Значение по умолчанию: количество логических ядер процессора компьютера, на котором исполняется ibcmd.

Несколько моментов, которые стоит учесть при подборе начального значения --jobs-count:

1. Утилита ibcmd ограничена одной NUMA, т.е. если у вас на сервере 48 ядер и 2 NUMA, то максимально утилита сможет занять только 48/2=24 ядра.
2. Это потоки на чтение, а есть же ещё и потоки на запись, поэтому для начала нужно поделить наши 24 ядра ещё на 2 и получим уже 12.
3. Поскольку это чтение, то точно имеет смысл включить параллелизм на MS SQL увеличив параметр MAXDOP. А вот насколько его увеличивать тут надо посчитать.
Опять же, если у нас на сервере СУБД 96 ядер, а мы читаем в 12 потоков, то нужно 96/12=8.

▫️ Количество потоков записи (--target-jobs-count) Значение по умолчанию: количество логических ядер процессора компьютера, на котором исполняется ibcmd.

Что нужно учесть при подборе параметра --target-jobs-count:

1 и 2 пункты те же самые что и у --jobs-count, т.е. в итоге получим 12
3. Поскольку это запись, то она всегда однопоточная на СУБД, но после записи у нас начнут создаваться индексы, а PostgreSQL нам позволяет распараллеливать именно эту операцию указывая параметр max_parallel_maintenance_workers (максимальное число рабочих процессов, для CREATE INDEX) и при этом не забываем что «сверху» число параллельных процессов ограничено параметром max_parallel_workers.
Соответственно при 96 ядрах на СУБД PostgreSQL и 12 потоков записи у ibcmd нам можно указать 96/12= 8 у max_parallel_maintenance_workers и max_parallel_workers = 96.

Так же будет очень полезно увеличить параметры work_mem (оперативная память на сеанс для операций ORDER BY) до 2-4 ГБ и maintenance_work_mem (Лимит памяти для CREATE INDEX) до 4-8 ГБ.
Учитывая, что у нас 12 потоков, то 12*4*8 = 384ГБ и это может быть максимум 50% всей доступной оперативной памяти.

▫️ Количество строк в порции данных (--batch-size) Количество строк в порции данных, используемой при репликации таблицы. Значение по умолчанию: 10 000

Казалось бы, ну а тут то что ещё считать, 10 000 вроде должно хватить всем?
Подбор этого параметра можно осуществить только тестами миграции и чтением лога PostgreSQL, в котором фиксируем операции длительнее 0,5 сек (log_min_duration_statement = 500ms) сравниваем скорость записи при умолчательном параметре 10 000, а затем увеличивая его на те же 10 000 пока скорость не начнёт падать.
У нас на серверах этот параметр получился оптимальным по скорости при значении 50 000.

▫️ Объем пакета данных (в байтах) (--batch-data-size). Значение по умолчанию: 10 485 760.
Ну и в целом похожий по смыслу на параметр --batch-size, только теперь в объёме памяти, а не количестве строк. Тут к сожалению, только подбор замером времени полной миграции при разных параметрах.
Опять же у нас оптимальным вышло увеличение и этого параметра в 5 раз до значения 52 428 800.

❗️Напомню, что по моему убеждению большая у вас база или нет определяется не её размером, а размером тех. окна и успеваете ли вы в это тех. окно сделать нужные вам монопольные операции или нет.
Миграция с СУБД на СУБД это одна из самых "больных" операций в части тех. окна и подбор параметров как ibcmd так и обоих, участвующих в этом процессе серверов СУБД может существенно и даже на порядок сократить это самое тех. окно.

Ну и на всякий случай канал в MAX https://max.ru/explorer1c