Тюнинг 1С:ERP и Postgres Pro под нагрузкой 300+ пользователей

Когда размер рабочей базы 1С:ERP превышает 500 ГБ, а число активных сессий переваливает за три сотни, типовая установка СУБД и серверов приложений неизбежно сталкивается с эскалацией блокировок. Проведение документов начинает занимать минуты, регламентные задания тормозят оперативную работу, а в логах учащаются таймауты (TTIMEOUT) и взаимные блокировки (TDEADLOCK).

Частая реакция бизнеса в такой ситуации — планирование закупки более мощного «железа». В этом кейсе команда Noxet разбирает, как с помощью детальной диагностики технологического журнала, тюнинга параметров ядра Linux и глубокой настройки Postgres Pro Enterprise мы ускорили проведение документов в 15 раз на существующей аппаратной базе.

Исходная ситуация и аппаратный профиль

• Конфигурация: 1С:ERP Управление предприятием (нетиповая, со значительным объемом доработок логики списания остатков).
• База данных: 560 ГБ на СУБД Postgres Pro 14 Standard (Linux РЕД ОС 7.3).
• Пользователи: 320 одновременно работающих сессий (толстый и тонкий клиенты через RDS-ферму).
• Симптомы: Зависания проведения заказов и реализаций до 120–180 секунд в пиковые часы (11:00–14:00), частые ошибки «Превышено время ожидания предоставления блокировки».

1. Диагностика узких мест через Технологический журнал 1С

Вместо слепых правок конфигураций мы подключили технологический журнал 1С (logcfg.xml), изолировав проблемные события:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="/var/log/1c/techlog/locks" history="72">
    <event>
      <eq property="name" value="TLOCKS"/>
      <ge property="duration" value="3000000"/> <!-- от 3 секунд -->
    </event>
    <event>
      <eq property="name" value="TTIMEOUT"/>
    </event>
    <event>
      <eq property="name" value="TDEADLOCK"/>
    </event>
    <property name="all"/>
  </log>
  <log location="/var/log/1c/techlog/db" history="24">
    <event>
      <eq property="name" value="DBPOSTGRS"/>
      <ge property="duration" value="5000000"/> <!-- тяжелые запросы > 5 сек -->
    </event>
    <property name="all"/>
  </log>
</config>

Анализ метрик показал:

1. Проблема не в процессоре: Утилизация CPU на сервере СУБД не превышала 45%.
2. Очереди дисков: Резкие скачки await до 40 мс при сбросе грязных страниц памяти (dirty pages) демоном kswapd.
3. Конфликты на регистрах накопления: 80% всех таймаутов блокировок приходились на регистр накопления «ТоварыНаСкладах» из-за избыточных транзакционных блокировок и неоптимального порядка списания партий.

2. Тюнинг ядра Linux (Kernel & Memory)

Для серверов баз данных под управлением Linux настройки подсистемы виртуальной памяти по умолчанию категорически не подходят для 1С:

# /etc/sysctl.d/99-postgresql.conf

# Запрет вытеснения страниц PostgreSQL в swap при наличии свободной RAM
vm.swappiness = 1

# Предотвращение накопления больших объемов грязных страниц
# Сброс на диск начинается при 5% грязной памяти и становится синхронным при 10%
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

# Защита от перегрузки виртуальной памяти
vm.overcommit_memory = 2
vm.overcommit_ratio = 80

# Отключение Transparent HugePages (THP) во избежание латентных задержек дефрагментации
# echo never > /sys/kernel/mm/transparent_hugepage/enabled

3. Оптимизация параметров Postgres Pro под специфику 1С

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

# postgresql.conf (Сервер: 128 ГБ RAM, 32 ядра CPU, NVMe SSD)

# Память
shared_buffers = 32GB                  # 25% от общего объема RAM
effective_cache_size = 96GB            # 75% RAM
work_mem = 64MB                        # Лимит на сложные сортировки и хеширование
maintenance_work_mem = 4GB             # Ускорение VACUUM и перестроения индексов
temp_buffers = 32MB                    # Память под временные таблицы 1C

# Планировщик и дисковая подсистема
random_page_cost = 1.1                 # Отражает высокую производительность NVMe
effective_io_concurrency = 200
seq_page_cost = 1.0

# Специфика 1С:Предприятие
max_locks_per_transaction = 256        # 1C удерживает множество табличных блокировок
standard_conforming_strings = off
escape_string_warning = off
row_security = off

# Тонкая настройка Autovacuum
autovacuum = on
autovacuum_max_workers = 6
autovacuum_naptime = 15s               # Частое сканирование изменений
autovacuum_vacuum_scale_factor = 0.05  # Запуск очистки при изменении 5% строк
autovacuum_analyze_scale_factor = 0.02 # Пересчет статистики при 2% изменений
autovacuum_vacuum_cost_limit = 2000    # Снятие ограничений по дисковому I/O для вакуума

# Расширения 1С (Postgres Pro Enterprise)
plantuner.fix_empty_table = on         # Коррекция планов для пустых временных таблиц
online_analyze.enable = on
online_analyze.table_type = 'all'

4. Реконфигурация кластера серверов 1С

Чтобы исключить взаимное влияние пользовательских сессий и тяжелых выгрузок, кластер серверов 1С был разделен по ролям:

1. Изоляция регламентных заданий: В консоли администрирования 1С создан выделенный рабочий сервер с включенным признаком «Использовать для регламентных заданий». Фоновые расчеты себестоимости и закрытия месяца перестали конкурировать за ресурсы с интерактивными пользователями.
2. Параметры рабочих процессов (rphost):
   • Количество ИБ на один процесс: ограничено до 1.
   • Количество соединений на один rphost: установлено в 25.
   • Ограничение объема памяти на процесс: 4096 МБ (предотвращение утечек памяти при неоптимальных клиентских отчетах).
   • Интервал перезапуска процессов: 86400 с (раз в сутки в нерабочее окно для устранения фрагментации памяти).

5. Результаты оптимизации

Финансовый эффект:

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

Если ваша система 1С испытывает проблемы с блокировками, производительностью СУБД или требует перехода на PostgreSQL — обратитесь за инженерным аудитом в Noxet.