Настройка параметров ibcmd в режиме replicate, а так же СУБД транслятора и СУБД приёмни... — 28 июля 2026 г. в 01:15:19.126
Настройка параметров 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 так и обоих, участвующих в этом процессе серверов СУБД может существенно и даже на порядок сократить это самое тех. окно.