Катастрофическое падение скорости при обновлении

В последнее время флагманские конфигурации 1С выпустили достаточно «тяжёлые» обновления ERP, УХ, KA и т.д.

Особенностью этих обновлений, помимо большого количества реструктуризаций объектов так же является большое количество монопольных обработчиков после обновления (это когда идёт «градусник» в пользовательском режиме) и вход в 1С заблокирован.

Мы в рамках инцидентов РКЛ уже несколько раз столкнулись с тем, что процесс этого монопольного обновления затягивается на несколько часов или даже суток!

Систематизация проблемы показала, что она существует только при использовании MS SQL и при этом полностью отсутствует на PostgreSQL и там этот этап проходит буквально за минуты.
Дальнейший анализ показал, что проблема возникает не всегда и не у всех – что с одной стороны сильно затрудняет её решение (так как по классике – такая же нога и не болит), с другой стороны есть что с чем сравнить (тех у кого быстро и тех у кого медленно, при сопоставимом количестве записей в регистрах – чтобы ощутить проблему, этих записей должны быть миллионы и десятки миллионов).

Разбор процедур обработчика показал, что происходит регистрация к изменению всех строк определённых регистров для дальнейшей постобработки в фоновом режиме, когда вход пользователей уже возможен, но функционал может быть ограничен.

Тонкость регистрации изменений состоит в том, что сначала проверяется есть ли уже такие зарегистрированные изменения (на уровне СУБД это запрос SELECT), и если таковых нет, то происходит уже сама регистрация (на уровне СУБД это запрос INSERT).

И по Технологическому журналу 1С мы получали чудовищную деградацию скорости именно при SELECT, если по началу он длился тысячные доли секунды, то затем вырастал до десятков секунд.

Разбор плана запроса показал что статистика чудовищно ошибается в предположении сколько строк уже зарегистрировано, например статистика предполагает что их 638 шт, а по факту оказывается 3 564 175 шт.

А у тех у кого обновление было быстрым – статистика не ошибалась…

В итоге было обнаружено, что всему виной отключенный Автоматический расчёт статистики на базе (аналог autovacuum_analyze в PostgreSQL) – на картинке видно где это включается.

Причина отключения достаточно известна – есть прекрасная статья, конкретно отключение автообновление статистики начинается с заголовка «Нестандартные ожидания на блокировках».

Что делать?
❗️Выключать автообновление статистики нужно только если вы фиксируете ожидания с типом LCK_M_SCH_S.
Придётся теперь следить и за этим параметром, и включать автоматический расчёт статистики, если вы ожидаете огромный объём регистрации к изменению.
Ну а при обновлении конфигурации – нужно включать автоматический расчёт на постоянной основе, просто как часть процесса и только после окончании всех процессов обновления, в том числе и фоновых уже выключать автообновление статистики, если на вашей базе это необходимо.

Как понять хватает ли памяти серверу PostgreSQL

Это очень интересный вопрос, так как на него нет ни простого ни точного ответа…

Для начала нужно разделить потребляемую память на 2 вида:
▫️ Память на соединение
▫️ Память на весь сервер

Сначала давайте попробуем понять, как мониторить хватает ли нам памяти на соединение?

Для ограничения потребления памяти в сеансе используется 3 параметра temp_buffers, work_mem и maintenance_work_mem.

Для отслеживания достаточности у нас есть на данный момент только один инструмент – логирование имён и размеров временных файлов, которое включается параметром log_temp_files.
Итак, допустим у нас temp_buffers = 128 MB, work_mem = 256 MB, а maintenance_work_mem = 512 MB тогда параметр log_temp_files лучше всего задать равным меньшему из этих значений, т.е. log_temp_files = 128 MB.

Тогда, в логах будет может появиться запись вида:

СООБЩЕНИЕ:  временный файл: путь "base/pgsql_tmp/pgsql_tmp33513.6.sharedfileset/0.0", размер 317964288

Как видно, был создан временный файл размером 317 964 288 байт.
А ниже этой строчки будет строка с текстом запроса, который вызвал создание временного файла такого размера:

ОПЕРАТОР:  CREATE UNIQUE INDEX _inforg2483_2 ON public._inforg2483 USING btree (_fld12588, _fld4134rref, _fld4133_type, _fld4133_rtref, _fld4133_rrref);

И вот тут придётся соотносить смысл запроса с параметрами, ограничивающими потребление оперативной памяти на сеанс, в данном примере этот временный файл был сформирован в оперативной памяти, так как параметр maintenance_work_mem больше чем размер файла.
А дальше делать вывод – повышать ограничение, если это не разовая, а массовая операция и при этом оперативки ещё много, а диски уже взывают о помощи.
Или пренебречь разовыми выплесками и оставить настройки как есть.
С другой стороны, если за релевантный для вашей системы период в логах нет таких записей, то стоит понизить значение параметра log_temp_files, например в 2 раза и собрать информацию.
Затем, возможно принять решение об уменьшении параметров, так как оперативки на сервере уже не хватает.

Теперь давайте посмотрим что у нас с памятью на сервер?
За объём выделенной памяти отвечает параметр shared_buffers, который по умолчанию рекомендуется ставить в 25% от всей оперативной памяти сервера.

Тут одновременно и сложнее и интереснее…

В анализе нам очень поможет расширение pg_buffercache.
Оно работает на таблицу, поэтому перед использованием необходимо выполнить команду создания расширения: CREATE EXTENSION IF NOT EXISTS pg_buffercache;
После этого мы можем узнать общее состояние буфера командой pg_buffercache_summary();
Ну и тут будет сразу видно, если у вас число неиспользуемых буферов buffers_unused достаточно большое относительно числа используемых buffers_used, то видимо переборщили с количеством кэша и его можно уменьшить.
❗️Важное замечание – параметр shared_buffers задаётся в байтах, а значения полей buffers_unused и buffers_used выдаётся в количестве буферов, один буфер = 8КБ.

❗️Ну и наконец, с помощью этого расширения мы можем узнать какие именно таблицы базы и сколько именно буферов в общем кэше занимают.
Это можно получить следующим запросом на каждую базу, который выдаст 20 таблиц-лидеров потребления кэша:

SELECT current_database() AS database_name, CASE WHEN d.relname IS NULL THEN c.relname ELSE d.relname END AS table_name,
count(*) AS buffers_size, cast (100*count(*)/cast ((SELECT buffers_used + buffers_unused FROM pg_buffercache_summary()) as numeric) as numeric(5,2)) AS percent_buffers_used
             FROM pg_buffercache b JOIN pg_class c
             ON b.relfilenode = pg_relation_filenode(c.oid) 
    LEFT JOIN pg_class d
    ON c.oid = d.reltoastrelid 
    AND b.reldatabase IN (0, (SELECT oid FROM pg_database WHERE datname = current_database()))
             GROUP BY CASE WHEN d.relname IS NULL THEN c.relname ELSE d.relname END
             ORDER BY 3 DESC
             LIMIT 20;

Напоминаю про канал в MAX, мало ли...

Почему добавление ресурсов может привести к «слёту» программной лицензии 1С

Мы же с вами чётко помним, что программная лицензия «слетает» только при удалении, а не при добавлении устройств, которые были в системе на момент активации лицензии.
Но при этом часто видим историю, когда именно добавление ресурсов виртуальной машины приводит к тому что лицензия становится неактуальной.
Например, нам понадобилось увеличить объём оперативной памяти виртуальной машины – кажется, что это почти тоже самое что добавить в физический сервер плашку оперативки.

«Да, но нет» - часто, чтобы увеличить объём памяти гипервизор виртуальной машины меняет ей модель процессора, и в итоге мы получаем не только добавление памяти, но и смену ЦПУ.

То же самое касается добавления ядер или увеличения суммарной герцовки ЦПУ у виртуалки, в итоге мы получаем именно изменение (удаление старого ЦПУ и добавление нового).

Ситуацию усугубляет то, что после подобных изменений 1С может спокойно запуститься и работать видя все лицензии. Администратор уверен, что значит всё прошло хорошо и переактивировать ничего не требуется.
А потом в «неожиданный» момент система перестаёт воспринимать лицензии.
Такое поведение возможно, так как параметры привязки лицензии к параметрам ПК проверяются не чаще одного раза в сутки.
Это не значит что у нас есть 24 часа после любых изменений!
Это значит что у нас есть сколько-то времени (сколько неизвестно) до следующей проверки параметров.

❗️Ну и наконец, есть ещё один очень важный момент!
Как я написал выше «мы же с вами чётко помним…», так вот, оказывается что мы помним это со времён версии Лучшей в мире платформы 1С 8.3.11!!!
Напомню, что последний релиз этой ветки вышел чуть более 8 лет назад 13/05/2018 года.

А уже с версии 8.3.12 описание поменялось на «Если в процессе работы будет изменен хотя бы один из ключевых параметров, то будет необходимо повторно активировать программную лицензию (с использованием нового пин-кода). Параметры компьютера опрашиваются не чаще одного раза в сутки.». Вот ссылка , на ИТС для 27 версии и ИТС для 12 версии платформы ветки 8.3. ну и на всякий случай для версии 8.5.4

Итак, правильный порядок действий при планировании изменений параметров железа и при самом изменении этих параметров:
1. Проверяем что у нас есть запасной пин-код для всех программных лицензий, активированных на данном ПК.
Если у вас нет пин-кода, то его можно или получить на сайте https://portal.1c.ru/support/license в онлайн режиме или запросить у 1С по почте lic@1c.ru.
Количество пин-кодов не ограничено, но получить можно только один пин-код за один раз. Получить 10 шт на всякий случай не выйдет.
2. Точно знать какой пин-код активирован на данный момент, его будет необходимо указать при активации нового
3. Провести изменение оборудования
4. Переактивировать все программные лицензии

Всем привет!

18 июня, 17-30
Новосибирск, Ядринцевская 21
1С митап CDEK
https://cdek-meetup.timepad.ru/event/4010555/

Приходите, будет интересно!
После выступления отвечу на все вопросы, какие накопились!)

Смена dbowner у базы 1С на PostgreSQL

Согласно check-list по настройке 1с рекомендуется «для каждой продукционной информационной базы создавать отдельного пользователя».
Так же Информационная безопасность тоже требует чтобы мы работали под уникальными пользователями с каждой базой и при этом у этих пользователей нужен только минимально необходимый набор прав.

Казалось бы, что может быть проще?
Ну выполним аналог команды MS SQL

EXECUTE sp_changedbowner 'ERP';

и готово.

Но оказалось что всё не так просто, а иногда и невозможно…

❗️Так повелось у многих, что создаём базы не просто из под пользователя с правами SUPERUSER, а именно из под пользователя postgres.

Какие пути решения есть:
1. Сменить владельца базы

ALTER DATABASE "ERP" OWNER TO "ERP";

Получаем следующие эффекты:
❗️Владельцем таблиц остаётся postgres.
Ок, мы не робкого десятка и умеем писать скрипты...
В цикле бежим по всем таблицам и выполняем

ALTER TABLE OWNER TO

❗️Но при запуске 1С пишет «База данных непригодна для использования»…

Дело в недостаточном разрешении для lc_messages
Ок, выполняем

grant set ON PARAMETER lc_messages to " ERP ";

❗️И всё равно при запуске базы получаем:

42501: ERROR: must be owner of extension mchar

🚫И вот тут первое нерешаемое – назначить владельца для расширения невозможно.

2. REASSIGN OWNED - Команда затрагивает только объекты в текущей базе данных. Обычно её нужно выполнять в каждой базе данных, которая содержит объекты, принадлежащие удаляемой роли.
Как раз то что нужно!!!
Если бы мы изначально не создали базу из под пользователя postgres

Команда

REASSIGN OWNED BY postgres TO ERP

❗️– не выполнится, с ошибкой: Изменить владельца объектов, принадлежащих роли postgres, нельзя, так как они нужны системе базы данных.

⛔️Всё, тупик. К сожалению, для баз созданных из под postgres, изменить полноценно владельца невозможно!

И тут решение только одно – dump/restore базы во вновь созданную, владельцем которой назначен другой пользователь без прав SUPERUSER.

Ну а на будущее – после разворачивания сервера PostgreSQL нужно первым же делом создать себе нового пользователя с правами SUPERUSER и работать под ним, а Супер-SUPERUSER postgres оставить на крайний случай прописав ему например доступ только по 127.0.0.1 в pg_hba.conf

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

Pg_dump это не только ценный бэкап, но и средство диагностики целостности базы

На этой неделе столкнулись с очень интересной проблемой.

Проявлялось это так:
- 1С практически не шевелится
- Если удалось зайти в 1с, то при совершенно разных операциях получаем ошибки СУБД с разным набором таблиц, которые почти ни о чём не говорят, кроме как что-то пошло не так
- Нагрузка ЦПУ на сервере PostgreSQL под 100%

Запрашиваем список активных сессий на СУБД

select * from pg_stat_activity

И получаем список транзакций. Которые длятся минуты и десятки минут с текстом:

select * from public._scheduledjobs...;

и т.д.

Попытка завершить транзакции средствами СУБД ни к чему не приводит.

Тем временем прод стоит, паника нарастает…

Всё это происходит на PostgresPRO Enterprise с встроенным кластером BiHA.
Система определяет что мастер не отвечает и перекидывает всю нагрузку на другую ноду кластера – всё совершенно корректно, как доктор прописал!
И что мы видим? – Буквально за 10 минут теперь и "новый мастер" так же уходит в нагрузку по ЦПУ в 100%.

Снимаем отладочную информацию со всех процессов мастера и «нового» мастера командой

kill <pid> -40

для ТехпПоддержки PostgresPro.

И хоть я и очень не люблю так делать, но аварийно останавливаем PostgreSQL через

kill <pid> -9

и на мастере и на «новом» мастере.

Блокируем 1С.
Стартуем PostgreSQL.

И для быстрой диагностики запускаем vacuum analyze only в несколько потоков на базе.
И опять получаем «зависшие» транзакции analyze на разных scheduledjobs…

Поясню – analyze читает не все данные в таблице, а только количество строк = 300*default_statistic_target. Обычно default_statistic_target = 100, т.е. мы читаем только 30 000 строк в таблице, и даже при этом уже получаем зависание системы.

Вот это уже страшно… Опять снимаем crash_info, рестартуем службу Postgres и начинаем расстраиваться…

Всё больше подозрений на битые страницы данных…
И тут встаёт вопрос, как быстро проверить все данные в базе?

Ответ – pg_dump, ведь по сути это select * по всем таблицам базы и сбор информации о DDL схемах как самих таблиц, так и индексов.

Но, база не маленькая и дамп будет формироваться достаточно долго…

Вспоминаем что можно вместо сохранения дампа на диск отправить его в «чёрную дыру» /dev/null, но при этом сохранив логи самого процесса дампа.

pg_dump -h 127.0.0.1 -p 5432 -U postgres -d ERP> /dev/null 2> dump.log

Такой дамп формируется намного быстрее.
Запускаем и получаем в логе сообщение:
pg_dump: ошибка: ошибка при выполнении запроса: ERROR: index "pg_attribute_relid_attnum_index" contains unexpected zero page at block 2349
ПОДСКАЗКА: Please REINDEX it.

Вот это поворот! Что-то не так с данными системной таблицы атрибутов..
Ну чтож, есть подсказка, давайте ей и воспользуемся:

REINDEX TABLE pg_catalog.pg_attribute;

И после этого опять запускаем analyze, чтобы проверить починилось ли и да, база починилась, analyze прошёл.
Запускаем 1С – проверяем, всё работает.
Запускаем пользователей и естественно у них «такая же нога, но болит!..», а именно, при различных операциях получаем ошибку СУБД с текстом:

ERROR: heap tid from tuple … offset 204 of block 4 in index “pg_namespace_nspname_index”…

Запускаем

REINDEX INDEX pg_namespace_nspname_index;

- ошибка ушла.

Причина по которой разрушились системные индексы пока ещё выясняется.
❗️Сама история говорит о том, что базу надо периодически регламентно проверять на целостность, а лучше не базу, а весь кластер командой:
pg_dumpall -h 127.0.0.1 -p 5432 -U postgres > /dev/null 2> dump.log
При этом лог будет пустой, если дамп не обнаружит ошибок.
Если же хочется иметь лог всей работы дампа в любом случае, то команда будет такой:

pg_dumpall -h 127.0.0.1 -p 5432 -U postgres -v > /dev/null 2> dump.log

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

16/06/2026 вышел релиз Postgres PRO Enterprise 18.4.1, где добавлена поддержка операций чтения и записи для временных таблиц, временных последовательностей и временных представлений на сервере горячего резерва.

Ранее писал о нашем тестировании этого механизма:
https://t.me/explorer1c/63?single
https://max.ru/explorer1c/AZ12VKRVZj4

Прорыв блокировок на MS SQL через Управляемые

Недавно разбирали очень странную проблему…
На MS SQL фиксировалось огромное количество таймаутов, при том что конфигурация на управляемых блокировках и по идее таймауты если могут быть, то должны фиксироваться на уровне 1С с событием TTIMEOUT, а не EXCP

Пользователи сотни раз в час получали сообщение вида:

Конфликт блокировок при выполнении транзакции Microsoft SQL Server Native Client: Превышено время ожидания запроса на блокировку

При этом виновниками блокировок судя по анализу таймаутов на СУБД были совершенно безобидные запросы select…
Но по мимо них и update, и insert, и delete, да ещё и на разных таблицах…
Т.е. никакой системности, никакого одного подозреваемого и совершенно непонятное поведение СУБД.
Как будто мы работаем на автоматических, а не на управляемых блокировках…

Долго ломали голову с какой стороны подойти даже к анализу, не то что к решению проблемы, так как по ощущениям в системе не просто проблема, а «ушиб всей бабки»…

Запрос:
SELECT DB_NAME(tl.resource_database_id) AS database_name, tl.request_session_id, tl.request_mode AS lock_type,* FROM sys.dm_tran_locks tl WHERE DB_NAME(tl.resource_database_id) = 'erp' ORDER BY tl.request_session_id

Показывал очень странный вывод – в колонке resource_type была только запись OBJECT, что означает что виновник блокировки блокирует всю таблицу, а не конкретную запись/записи в ней

Если бы блокировались записи, то в колонке resource_type должна быть запись KEY.

Получается, что мало того что мы каким-то чудесным образом прорываемся сквозь управляемые блокировки, ещё и блокируем каждый раз таблицы целиком…

Но мы точно знаем – чудес не бывает!
На соседней базе, на этом же сервер СУБД выполняем запрос, который начинает транзакцию на чтение, внутри становится на паузу в 1С минуту, чтобы мы успели увидеть, что и как он блокирует
BEGIN TRANSACTION;
SELECT * FROM dbo._InfoRg178 T1 WITH (HOLDLOCK) WHERE T1._Fld80 = 'test'
WAITFOR DELAY '00:01:00';
COMMIT TRANSACTION;

И видим что СУБД совершенно корректно блокирует по KEY, т.е. конкретную запись в таблице.
Такой же запрос в проблемной базе, блокирует всю таблицу – OBJECT
Значит разница именно в какой настройке в базе, а не в сервере СУБД.

В итоге – нашли!

А именно: https://its.1c.ru/db/metod8dev/content/5837/hdoc
Важно! Начиная с версии платформы 8.3.22 необходимо выполнять дефрагментацию индексов по следующему алгоритму:
До дефрагментации индекса необходимо включить страничные блокировки. Пример команды: ALTER INDEX index_name ON table_name SET (ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON);
Выполнить дефрагментацию.
Обратно выключить страничные блокировки. Пример команды: ALTER INDEX index_name ON table_name SET (ALLOW_PAGE_LOCKS = OFF, ALLOW_ROW_LOCKS = ON);

При этом в плане обсуживания проблемной базы в самом последнем шаге устанавливается ALLOW_ROW_LOCKS = OFF
Что отключает у MS SQL возможность использовать индексы и SQL Server будет вынужден использовать только табличные блокировки

Вывод – читать документацию нужно очень внимательно, там всё написано верно, но так, что может и ввести в заблуждение)))
И проверьте свои планы обслуживания баз на MS SQL

Вчера получил несколько десятков вопросов с непониманием - что всё таки явилось причиной блокировок, описанных в https://t.me/explorer1c/75

❗️Итак:
Причиной проблемы был установленный параметр ALLOW_ROW_LOCKS = OFF для всех индексов всех таблиц базы.

Причём тут документация?
На ИТС написано:
До дефрагментации индекса необходимо включить страничные блокировки. Пример команды:

ALTER INDEX index_name ON table_name SET (ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON);

Выполнить дефрагментацию.
Обратно выключить страничные блокировки. Пример команды:

ALTER INDEX index_name ON table_name SET (ALLOW_PAGE_LOCKS = OFF, ALLOW_ROW_LOCKS = ON);

Т.е. речь всегда идёт только о страничных блокировках, это параметр ALLOW_PAGE_LOCKS.
Но в примерах команд есть ещё и параметр ALLOW_ROW_LOCKS , который вообще-то и в первом скрипте (Перед дефрагментацией индексов) и во втором (после дефрагментации) установлен в значение ON.

Но поскольку текстом написано включить и после дефрагментации выключить, то читается это как выключить всё что было включено.
Что и явилось причиной неверного плана обслуживания, где после дефрагментации был выключен параметр ALLOW_ROW_LOCKS=OFF.

Проверить наличие такой настройки в индексах базы можно запросом:

select object_id, name, allow_row_locks from sys.indexes where allow_row_locks = 0

По дороге на ИТ-ночь https://ciocdo.ru/meropriyatiya/kupala2026/?ysclid=mqurz0d71y639102609

В этот четверг 02/07 в 10-00 по Мск (14-00 по Нск) вебинар по возможностям КОРП-платформы 1С и новшествам PostgreSQL для высоких нагрузок.

Ну и конечно ответы на все вопросы, какие накопились.

Приходите, будет интересно!)

Тонкости настройки пулов приложений IIS для 1С

Веб сервер от Microsoft - Internet Information Services (IIS) до сих пор очень популярен в инфраструктуре 1С, да я и сам его очень люблю за удобство и гибкость!

Взаимодействие с 1С устроено через пулы приложений IIS.
Это с одной стороны очень удобно и позволяет на одном порту опубликовать базы 1С разных версий Лучшей в мире платформы 1С!
Например базу ERP опубликовать на версии 8.3.27, а базу ZUP на версии 8.5.1 и при этом базы будут иметь один и тот же адрес сервера и порт https://web-server-erp и https://web-server/zup

▫️И тут кроется первая тонкость настройки:
Часто приходится встречаться с проблемой когда база 1С то работает по http то нет…
Естественно – никто ничего не трогал, вчера всё работало! 😄

❗️Обычно причина такого поведения кроется в том, что внутри одного пула приложений в сопоставлении обработчиков для разных баз 1С прописаны разные версии платформы 1С.
В этом случае в пул загружается та версия, которую раньше всех вызвали после перезапуска пула, а пул периодически перезапускается – по умолчанию после 20 минут простоя.

Правильно делать так:
Внутри одного пула приложений должна быть прописана одна версия платформы 1С в сопоставлении обработчиков.
После обновления версии 1С в сопоставлении обработчиков пул приложений лучше всего перезапустить.

▫️Вторая тонкость настройки касается тех инсталляций, где на одном пуле приложений работают сотни/тысячи сеансов, при чём не только пользовательских, но и http-сервисы, web-сервисы, odata, т.е. всё что идёт через веб-сервер.

Оказалось, что многопоточность рабочего процесса пула приложений IIS не бесконечна и при большом количестве соединений он начинает подвисать, что пользователями воспринимается как периодическое подтормаживание 1С…
Мы очень долго выясняли причину такого поведения, методом «научного тыка» подобрали что на нашем железе оптимальным являлась настройка Один рабочий процесс – 128 сеансов.
Но при этом количество рабочих процессов не должно быть больше количества ядер, доступных операционной системе.
Т.е. если мы рассчитываем что на это веб-сервере будет работать 2000 сеансов, то нам нужно 2000/128 = 16 рабочих процессов, а соответственно и ядер в системе нужно 16+2. Два ядра для работы остальных процессов Операционной системы.

❗️Ну и как это часто бывает, когда мы уже нашли себе ответ на вопрос, оказалось что он есть на ИТС - https://its.1c.ru/db/metod8dev/content/6034/hdoc, тут указано что расчёт нужно вести Один процесс - 100 соединений, очень похоже на наш вывод.

Правда мы столкнулись с проблемой ещё на 25-й версии платформы, и решение у нас выглядит сильно сложнее, с применением haproxy и «умной» балансировки нагрузки согласно знаниям devops системы о расположении баз 1С относительно кластеров 1С, и соединений там многие тысячи, но об этом расскажу в следующий раз.

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

Крайне важная новость для инфраструктур в которых есть KVM

Не секрет, что последние громкие публичные взломы и шифрования в основном делались на уровне взлома систем виртуализации.

В публичный доступ выложили уязвимость Januscape (CVE-2026-53359) в гипервизоре Linux KVM. Если у злоумышленника есть root-права внутри гостевой виртуалки, он может пробить изоляцию, выйти на уровень гипервизора на архитектуре x86 и получить полный контроль над физическим сервером и всеми остальными соседями по железу.
Ubuntu советует вырубить вложенную виртуализацию (nested virtualization).

По информации с securitylab.ru Исправление вошло в основную ветку Linux 19 июня этого года. Разработчики добавили проверку роли страницы, чтобы KVM повторно использовал её только при совпадении адреса и назначения. Исправленные стабильные ядра 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 и 5.10.260 вышли 4 июля.

❗️Крайне рекомендую всем обновить свои системы KVM в ближайшее время.

Настройка параметров 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

Утром в канале, вечером в Красноярске)

Открыто голосование за доклады на октябрьский Инфостарт

https://infostart.ru/event/tech2026/agenda/

Выбирайте, голосуйте, приезжайте!)