Настройка параметров 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, т.е. в итоге получим
123. Поскольку это запись, то она всегда однопоточная на СУБД, но после записи у нас начнут создаваться индексы, а 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 
