Тонкости настройки пулов приложений 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/

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

Системные администраторы, с праздником! 🎉🎉🎉

Именно системное администрирование было моим началом в ИТ)

Статистика по временным таблицам в PostgrePRO - другой подход

Сначала о проблематике:
В 1С мы с вами обожаем создавать и использовать в запросах временные таблицы, причём создавать и заполнять их тысячами в секунду в рамках одного сервера СУБД.

При этом лучшая в мире платформа 1С, после заполнения каждой временной таблицы даёт команду ANALYZE ##tt1, где ##tt1 имя нашей временной таблицы.

При этом статистика считается по каждой колонке временной таблицы.

Это влечёт за собой серьёзные траты ресурсов сервера на расчёт статистики именно по временным таблицам.

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

Кратко:
1. При включении параметра pgpro_temp_stats.skip_analyze - игнорируем команды ANALYZE по целым таблицам, т.е. пока не греем воздух просто расчётом статистики
2. При включении параметра pgpro_temp_stats.create_statistics - расширение считает статистику только по тем столбцам временной таблицы, которые задействованы в запросе.
Более того, считается не просто статистика, а расширенная статистика, т.е. не по каждому столбцу в отдельности, а по всем столбцам из запроса сразу.
Что позволяет планировщику получить более оптимальный план запроса.
3. Так же расширение запоминает уже посчитанную статистику для таблицы, так как мы же можем её и второй раз использовать. Если в новом запросе поля те же, то статистика не считается, так как она уже есть, если же поля другие, то считаем по новому набору полей.
Сколько таких запоминать регулируется параметром pgpro_temp_stats.ts_max_items

Расширение доступно в 17 и 18 версиях PGRPO Enterprise.

Мы протестировали - нам понравилось!)

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

Сегодня особенный день — мой день рождения!
Хочу поблагодарить всех, кто делает мою жизнь ярче и интереснее. Каждый день я учусь чему-то новому и встречаю замечательных людей.
Пусть этот год принесет ещё больше возможностей, успехов и приятных моментов. 🌟
С днём рождения меня! 🎂

P.S. С днем рождения мою сестру-двойняшку 😘

🎉🎉🎉🎉🎉🎉

Дампы аварийного завершения процессов 1С

В последнее время достаточно часто сталкиваемся с тем что сбор дампов или не настроен, или настроен не совсем верно, или приводит к окончанию места на диске...
А тем временем причину падения процесса без разбора дампа понять бывает или очень трудно или вообще невозможно.

Так как же настроить сбор дампов и сделать так чтобы это не приводило к падению сервера по нехватке места на диске?

В настройке ТехЖурнала (файл logcfg.xml) для сбора дампов в ОС Windows (в Linux всё по другому) нужно добавить/отредактировать строку:
<dump location="D:\dumps\" create="1" type="3" externaldump="1"/>
Тип дампа (type) нужно поставить 3, так как это минимально необходимый объём информации для действенного разбора дампа.
Дамп такого типа при формировании будет иметь размер равным размеру оперативной памяти, которую занимал процесс на момент формирования дампа.

Очень важно указать location не на системном диске С и не на диске где у нас расположены сеансовые данные и/или каталог временных файлов пользователя процесса rphost.
Желательно выделить для этого отдельный логический/физический диск с объёмом свободного места не менее всего объёма оперативной памяти, так как в крайнем случае дамп будет размером во всю оперативку.

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

Настроить систему мониторинга или в самом скрипте архивации прописать сообщение ответственному админу 1С о факте формирования дампа.

Что делать с дампами потом и какие они бывают?

Дамп в ОС Windows имеет достаточно понятное имя файла:
<имя процесса>_<версия платформы>_<смещение>_<годмесяцденьчасминутасекунда>_<PID процесса>.mdmp
Например: rphost_8.3.27.1606_547f1b52_20260810051328_13432.mdmp

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

В имени много важной информации, и отдельно нас интересует смещение.
Если у нескольких дампов смещение одинаковое, то и причина падения с 99% вероятностью тоже одна, поэтому на расследование достаточно отправить пару дампов, а остальные просто сохранить в сторонке.

Если же смещение _00000000_, то такой дамп отправлять никуда не нужно.
Тут причина падения заранее известна и заключается в том, что процесс был убит Системой отслеживания разрыва соединений.

Это поведение зависит от настроек кластера 1С (на скриншоте), а именно:

❗️Менять их нужно крайне осознанно полностью понимая что делаешь, несколько раз прочитав документацию и поняв её!

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

Другие настройки это Период проверки (1000 мс) и Таймаут проверки (5000 мс), вот их нужно кратно увеличить до тех пор пока падения не прекратятся.

НО, сам факт таких дампов говорит о том что процессы реально не отвечают системе отслеживания и с этим нужно разбираться.
И о УЖАС - разбираться с этим нужно АДМИНИСТРАТОРАМ 1С, а не 1С-кам!!!

Вот выдержка из документации (ссылка выше), которая с этим поможет:

Для этого каждые 10 секунд в технологический журнал записывается статистика проверки соединений за прошедшие 10 секунд. В частности, выводится информация о среднем времени ответа и о максимальном времени ответа. Эта информация позволяет выставить оптимальные значения таймауты проверки, которые не будут приводить к ложным срабатываниям системы проверки, но, в тоже время, обеспечат надежное функционирование самой системы. В технологическом журнале информация фиксируется в событии CONN.

Плановая дата обязательного перехода на Платформу 8.5 для конфигураций ERP/KA/УТ– не ранее 30.04.2027

Многие спрашивают - сколько ещё сможем жить на ламповой 8.3?
Фирма 1С дала ответ.

https://1c.ru/news/info.jsp?id=34779

Так что пора уже понемногу планировать переход на 8.5.

❗Особенное внимание нужно уделить переходу на новый сервис лицензирования при наличии USB-ключей, так как 8.3 не видит новый сервис, а 8.5.4 не умеет работать с lm-hasp.

Небольшой анонс поездок и мероприятий с моим участием:

08-10/09 - Обучение по кластеру 1с и PostgreSQL, Москва
11/09 - Хакатон-ИнфоСофт, Новосибирск
18/09 - Жёлтая конфа, Москва
26-27/09 - Партнёрский семинар 1С, Москва
08-10/10 - Infostart Tech Event, Санкт-Петербург

Сентябрь беспощаден!)

Как собрать для анализа запроса все временные таблицы с их содержимым?

Все мы хорошо знаем, что количество временных таблиц, создаваемых и используемых во время работы 1С огромно.
Очень часто нам для оптимизации скорости работы 1С требуется не только текст запросы и его план, но и содержание временных таблиц.
А это огромная проблема – таблиц может быть много, записей в них могут быть и тысячи и миллионы…
Какие только инструменты для этого не пытались использовать, и ТехЖурнал с записью всех запросов к СУБД, и трассировку запросов на уровне СУБД. А потом сбор всех этих данных и формирование таблиц с содержимым на основании этих данных.
Было очень тяжело и всегда неохота этим заниматься…

Насколько мне известно при работе с MS SQL так ничего и не поменялось.
А вот в PostgreSQL появилось расширение auto_dump.
«На пальцах» что делает расширение:
Следит за текстом запросов dump_on_query_string и когда находит нужный (например UPDATE _AccRg), то делает бэкап всех временных таблиц и их содержимым (можно и физических, но по моему мнению это достаточно опасно, ниже опишу почему), собирает предполагаемый и фактический планы запроса, сохраняет текст самого запроса, складывает это всё в каталог указанный в параметре output_directory
Так же можно настроить чтобы собирались запросы только длительнее чем auto_dump.timeout
Или запросы у которых по нашему мнению плохой план из-за большой разницы в предполагаемых и фактических значениях bad_plan_count_threshold и/или bad_plan_percent_threshold

Чем опасен параметр dump_persistent_tables, который позволяет сразу дампить физические таблицы?
Тем что физические таблицы могут быть огромного объёма и в итоге мы получим и тормоза и забитый диск.
Поэтому включать этот параметр нужно только полностью понимая что вы делаете.

Как потом работать с полученной информацией уже запросами к СУБД напрямую:
1. Создаём новую пустую базу из 1С. Это делается для того чтобы были созданы функции и типы данных, которые использует 1С.
2. Делаем dump физических таблиц, которые есть в запросе.
3. Восстанавливаем из дампа таблицы в базу созданную в п.1
4. Выполняем скрипт create_temporary.sql по созданию временных таблиц, который нам создал auto_dump
5. Выполняем скрипт insert_temporary.sql по наполнению временных таблиц, который нам создал auto_dump
6. Выполняем запрос query.sql, который нам создал auto_dump, на уровне СУБД и пытаемся его оптимизировать настройками СУБД, добавлением индексов (понимая как потом мы их сможем добавить на уровне 1С), улучшать план запроса манипулируя параметрами сбора статистики, менять сам запрос на уровне СУБД опять же понимая как мы потом это на 1С напишем и т.д.

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

Начнём...)

Теперь на багборде можно легко и быстро сравнить версии платформы по изменениям!

Уверен что это сильно упростит ответ на самый популярный вопрос - "А на какую платформу переходить?")))

Сегодня ровно год первому сообщению в канале!
Огромное спасибо всем вам!
Честно - было очень страшно начинать и я надеюсь, что держу свои обещания публикуя только практические кейсы без рекламы и воды!

С годовщиной, "Маяк в мире 1С и СУБД" 🎉🎉🎉🎉🎉🎉🎉

Можно ли сделать поведение PostgreSQL в отношении потребления памяти процессами более жестким чем "мягкий предел"?

Кратко - да, можно))

Проблематику расхода памяти процессами вкупе с работой пула соединений 1С затрагивал в
https://t.me/explorer1c/39 и https://max.ru/explorer1c/AZvZrNDcSXU

Но это же только часть проблемы, есть сценарии и похуже, когда мы не можем никак повлиять через idle таймаут поскольку запрос выполняется...
И вполне может произойти ситуация, когда на выполнение запроса не хватит оперативной памяти и опять придёт охранник ОС OOMKiller и прекратит это безобразие...

В версии PosrgresPro Enterprise есть параметр max_backend_memory - он как раз таки задаёт максимальный объём памяти на один рабочий процесс и при его превышении прекращает выполнение запроса.

Очень полезная настройка на нагруженных кластерах СУБД, так как большая многопользовательская нагрузка когда-то упрётся в ограничение физических ресурсов и нам придётся прерывать конкретные сеансы ради продолжения работы всего сервера СУБД в целом.

Сейчас ведём работы совместно с командой PostgrePRO по следующей логике:

Раз мы как администраторы СУБД задали ограничение max_backend_memory, то значит когда мы прервали выполнение запроса, то будет логичным вообще завершить этот процесс аналогично механике idle_session_timeout, таким образом снижая вероятность перерасхода оперативной памяти в целом на сервере.

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