Ускорение 1С: тонкая настройка СУБД PostgreSQL на Linux без покупки нового сервера

В условиях импортозамещения многие компании переносят системы «1С:Предприятие» с Windows и MS SQL Server на стек Linux и PostgreSQL. Однако после миграции бизнес часто сталкивается с падением производительности: проведение документов зависает, отчеты формируются в разы дольше, возникают взаимные блокировки. Первая реакция руководства — покупка более мощного сервера. Но в 80% случаев проблема кроется не в нехватке физических ресурсов, а в неоптимальных стандартных настройках СУБД и ОС. По умолчанию PostgreSQL сконфигурирован под простые веб-приложения, а не под транзакционную нагрузку ERP-систем. Тонкая настройка имеющегося сервера позволяет увеличить производительность 1С в 2–3 раза без дополнительных затрат на оборудование.

Специфика работы 1С с базами данных и неэффективность настроек по умолчанию

Платформа «1С:Предприятие» создает транзакционную нагрузку типа OLTP (Online Transaction Processing). Она характеризуется миллионами мелких и быстрых запросов на чтение и запись от множества пользователей. Для таких систем критически важны минимальное время отклика (latency) памяти и дисков, а также быстрая обработка блокировок.

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

Стандартный PostgreSQL без оптимизации не подходит для 1С. Платформа требует специализированных сборок СУБД (например, от Postgres Pro или самой фирмы 1С), содержащих патчи для поддержки специфического упорядочивания символов (collation), оптимизации менеджера блокировок и планировщика запросов. Но даже специализированная сборка требует настройки под параметры конкретного сервера.

Подготовка и оптимизация Linux: тонкий тюнинг ядра

Перед настройкой PostgreSQL необходимо подготовить ОС. Оптимизация рассматривается на примере дистрибутивов Rocky Linux и Ubuntu Server.

Настройка профиля производительности CPU

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

cpupower frequency-set -g performance

Для сохранения настроек при загрузке в Rocky Linux используется утилита tuned:

tuned-adm profile network-latency

В Ubuntu установите утилиту sysfsutils и добавьте в /etc/sysfs.conf строку:

devices/system/cpu/cpu*/cpufreq/scaling_governor = performance

Настройка параметров виртуальной памяти (sysctl.conf)

Добавьте следующие параметры в файл /etc/sysctl.conf для оптимизации кэширования и работы с памятью:

vm.swappiness = 1
vm.overcommit_memory = 2
vm.overcommit_ratio = 80
kernel.sched_migration_cost_ns = 5000000
vm.dirty_background_bytes = 67108864
vm.dirty_bytes = 268435456

Логика этих параметров:

• vm.swappiness = 1 минимизирует сброс страниц памяти PostgreSQL в swap. Чтение буферов из swap приводит к катастрофическому падению скорости работы СУБД.
• vm.overcommit_memory = 2 запрещает ядру выделять памяти больше, чем доступно физически с учетом swap. Это защищает PostgreSQL от уничтожения процессом OOM-killer при резком росте нагрузки. Параметр vm.overcommit_ratio задает лимит использования ОЗУ в 80%.
• kernel.sched_migration_cost_ns = 5000000 снижает частоту миграции потоков PostgreSQL между ядрами CPU, повышая эффективность использования процессорного кэша.
• vm.dirty_background_bytes (64 МБ) и vm.dirty_bytes (256 МБ) заменяют стандартные лимиты сброса грязных страниц в процентах. Это заставляет ядро сбрасывать измененные данные на диск непрерывно и мелкими порциями, исключая длительные зависания дисковой очереди.

Отключение Transparent Huge Pages (THP)

Механизм Transparent Huge Pages объединяет стандартные страницы памяти 4 КБ в блоки по 2 МБ. Для СУБД с хаотичным доступом к данным THP вызывает фрагментацию ОЗУ и накладные расходы на уплотнение памяти. Для отключения THP добавьте параметр transparent_hugepage=never в строку загрузки ядра в файле /etc/default/grub и обновите конфигурацию загрузчика:

• В Ubuntu: update-grub
• В Rocky Linux: grub2-mkconfig -o /boot/grub2/grub.cfg

Файловая система, опции монтирования и планировщик

Для баз данных рекомендуется использовать файловую систему XFS. В файле /etc/fstab для раздела данных укажите опции noatime и nodiratime для предотвращения записи времени последнего доступа при каждом чтении:

/dev/mapper/vg-pgdata /var/lib/postgresql xfs defaults,noatime,nodiratime 0 0

Для современных SSD-дисков используйте планировщик deadline (или mq-deadline), а для NVMe-накопителей — планировщик none для исключения лишних очередей на уровне ОС:

echo none > /sys/block/nvme0n1/queue/scheduler

Стресс-тестирование дисковой подсистемы с помощью FIO и pg_test_fsync

Скорость дисков определяет производительность СУБД. Перед оптимизацией необходимо измерить реальные показатели IOPS и latency.

Тестирование дисков утилитой FIO

Установите пакет fio (apt-get install fio или dnf install fio). Запустите тест на случайную запись блоками по 4 КБ (имитация записи транзакционного лога WAL):

fio --name=randwrite --ioengine=libaio --iodepth=64 --rw=randwrite --bs=4k --direct=1 --size=4G --numjobs=4 --runtime=60 --group_reporting --filename=/var/lib/postgresql/test_fio_file

Для качественных корпоративных NVMe-дисков производительность случайной записи должна составлять не менее 40 000–60 000 IOPS, а средняя задержка (clat/latency) — не более 150–300 микросекунд (usec). Задержки в миллисекундах указывают на то, что диски будут узким местом системы.

Определение метода fsync с помощью pg_test_fsync

Запустите утилиту от имени пользователя postgres для проверки скорости системных вызовов фиксации данных на диске:

/usr/lib/postgresql/15/bin/pg_test_fsync -f /var/lib/postgresql/fsync_test.file

Обычно в PostgreSQL используется метод fdatasync, показывающий оптимальную производительность на большинстве Linux-систем.

Конфигурирование postgresql.conf: детальный разбор параметров

Рассмотрим настройку основного файла конфигурации /var/lib/postgresql/data/postgresql.conf. Для примера возьмем сервер с 64 ГБ оперативной памяти (RAM) и 16-ядерным процессором (CPU).

Имя параметра	Значение для 64 ГБ RAM / 16 CPU	Логика настройки и рекомендации
shared_buffers	16GB	Кэш страниц СУБД. Устанавливается равным 25% от физической оперативной памяти.
work_mem	128MB	Лимит памяти для одной операции сортировки или группировки в рамках одного запроса.
maintenance_work_mem	2GB	Память для регламентных операций СУБД (создание индексов, вакуум).
temp_buffers	64MB	Объем памяти под временные таблицы для одной сессии. Крайне важен для 1С.
effective_cache_size	48GB	Оценка общего объема кэша, доступного для СУБД (буферы СУБД + Page Cache ядра).
max_connections	150	Максимальное количество одновременных подключений.
synchronous_commit	off	Отключение ожидания физического сброса лога WAL на диск при фиксации транзакции.
fsync	on	Гарантия физического сброса буферов на диск. Должен быть включен в продакшене.
checkpoint_timeout	15min	Временной интервал между контрольными точками сброса грязных буферов на диск.
checkpoint_completion_target	0.9	Коэффициент сглаживания записи страниц во времени в течение таймаута чекпоинта.
max_wal_size	16GB	Максимальный объем файлов журнала WAL до принудительного чекпоинта.
min_wal_size	2GB	Минимальный объем журналов WAL, сохраняемый для повторного использования.
random_page_cost	1.1	Коэффициент стоимости случайного чтения страниц. Для SSD снижается с дефолтных 4.0.
effective_io_concurrency	200	Число параллельных операций ввода-вывода, обрабатываемых дисковой подсистемой.

Описание ключевых параметров конфигурации

#### shared_buffers Определяет объем ОЗУ, выделяемый под кэширование страниц СУБД. Оптимальное значение составляет 25% от памяти сервера. Установка более высоких значений (например, 50%) снижает общую скорость работы из-за эффекта двойного кэширования (так как Linux дублирует эти же данные в системном Page Cache) и повышает накладные расходы на блокировку буферов.

#### work_mem Задает объем ОЗУ для сортировок и хэш-таблиц перед записью во временные файлы на диск. Запросы 1С содержат множество вложенных соединений, поэтому значение должно быть достаточным (например, 128MB). Однако этот лимит выделяется на каждый шаг запроса индивидуально. При 150 подключениях одновременное потребление памяти может превысить ОЗУ сервера. Начинайте со 128MB и отслеживайте в логах предупреждения о создании временных файлов СУБД (temporary file), постепенно повышая параметр при необходимости.

#### temp_buffers Определяет лимит ОЗУ для временных таблиц в одной сессии. Так как 1С активно использует временные таблицы, увеличение параметра до 64MB позволяет удерживать большинство из них в быстрой оперативной памяти, минуя запись на диск.

#### synchronous_commit При значении off СУБД подтверждает завершение транзакции сразу после записи в буфер WAL в ОЗУ, не дожидаясь физического сброса на диск. Запись на диск выполняется асинхронно с задержкой до 20–50 мс. Безопасность данных: В случае сбоя питания могут быть потеряны транзакции за последние доли секунды, но сама база данных не повредится. При запуске PostgreSQL восстановит согласованное состояние. Для большинства баз 1С ускорение записи в 3–5 раз полностью окупает этот минимальный риск.

#### random_page_cost Для SSD/NVMe дисков случайный доступ выполняется с той же скоростью, что и последовательный. Установка значения 1.1 (вместо стандартного 4.0) сообщает планировщику, что случайное чтение дешево, и заставляет его чаще использовать индексный поиск вместо полного сканирования таблиц.

#### Параллельное исполнение запросов Для транзакционной базы 1С параллельное выполнение одиночных запросов неэффективно, так как накладные расходы на сборку результатов велики. Параллелизм должен использоваться только для регламентных процедур. Отключите параллельное выполнение для клиентских сессий и выделите ресурсы под обслуживание:

max_worker_processes = 16
max_parallel_workers_per_gather = 0
max_parallel_workers = 8
max_parallel_maintenance_workers = 4

Борьба с раздуванием (bloat) и регламентное обслуживание: autovacuum, analyze и pg_repack

В PostgreSQL измененные или удаленные строки физически не удаляются из таблиц сразу. Они помечаются как «мертвые» (dead tuples). Очисткой этих строк занимается фоновый процесс автовакуума (autovacuum). Если автовакуум не настроен, таблицы и индексы раздуваются (bloat), из-за чего СУБД считывает лишние гигабайты пустых страниц, замедляя работу 1С.

Настройка autovacuum для нагрузок 1С

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

autovacuum = on
autovacuum_max_workers = 4
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.02
autovacuum_vacuum_cost_limit = 1000
autovacuum_vacuum_cost_delay = 2

Параметр autovacuum_vacuum_scale_factor = 0.05 запускает очистку при изменении 5% строк таблицы (вместо 20% по умолчанию), а снижение задержки autovacuum_vacuum_cost_delay до 2 мс и увеличение лимита стоимости autovacuum_vacuum_cost_limit до 1000 ускоряют работу автовакуума в несколько раз.

Регламентные операции СУБД

Необходимо настроить запуск ночных регламентных задач через системный планировщик cron:

#### 1. Обновление статистики (ANALYZE) Статистика распределения данных в таблицах критически важна для правильного выбора индексов планировщиком. Запускайте сбор статистики для базы каждую ночь:

vacuumdb -U postgres -d your_database_name --analyze-only --verbose

#### 2. Переиндексация (REINDEX) Индексы 1С быстро фрагментируются. Команда REINDEX перестраивает их с нуля, повышая скорость поиска. Поскольку обычный REINDEX блокирует таблицы на запись, его запускают раз в неделю на выходных:

reindexdb -U postgres -d your_database_name

#### 3. Использование pg_repack для сжатия в режиме 24/7 Для круглосуточных баз данных используйте утилиту pg_repack. Она устраняет фрагментацию таблиц и индексов в фоновом режиме без наложения эксклюзивных блокировок. Установка в Ubuntu:

apt-get install postgresql-15-repack

Запуск сжатия конкретной таблицы без остановки работы пользователей:

pg_repack -U postgres -d your_database_name -t named_table

Что я делаю для этой сферы

• [ ] Аудит производительности 1С: Провожу детальный анализ технологического журнала 1С и логов СУБД для выявления причин медленной работы.
• [ ] Оптимизация параметров ядра Linux: Конфигурирую виртуальную память, профили CPU, THP и планировщики очередей ввода-вывода.
• [ ] Стресс-тестирование оборудования: Измеряю производительность накопителей (FIO) и процессора под максимальной нагрузкой.
• [ ] Тюнинг файлов конфигурации СУБД: Настраиваю лимиты памяти, параметры WAL и параллелизма под ресурсы сервера.
• [ ] Настройка планового обслуживания: Автоматизирую резервное копирование, агрессивный автовакуум и бесконфликтную переиндексацию баз данных.

Готовое решение по теме

• Связаться со мной в Telegram — оперативный технический разбор проблемы в чате.
• Группа ВКонтакте — кейсы администрирования баз данных, рекомендации и отзывы.
• Каталог услуг — прайс-лист на обслуживание серверов СУБД, 1С и систем на Linux.

Регламент обслуживания после тюнинга

Разовая настройка PostgreSQL даёт ускорение, но без регулярного обслуживания база со временем снова замедляется: накапливаются мёртвые строки, разрастаются индексы, меняется объём данных. Поэтому тюнинг закрепляется регламентом сопровождения.

Минимальный регламент обслуживания сервера 1С на PostgreSQL:

• Контроль автовакуума. Регулярная проверка раздувания таблиц и при необходимости ручное обслуживание тяжёлых регистров.
• Резервное копирование. Проверяемые бэкапы с регулярным тестовым восстановлением — бэкап, который не восстанавливается, бесполезен.
• Мониторинг ресурсов. Отслеживание нагрузки на диск, память и медленных запросов, чтобы ловить проблемы до жалоб пользователей.
• Обновление статистики. Пересчёт планов запросов после крупных загрузок данных и закрытия периодов.

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

Часто задаваемые вопросы (FAQ)

Безопасно ли отключать synchronous_commit? Не приведет ли это к потере или повреждению всей базы данных 1С?

Да, это безопасно. PostgreSQL использует механизм WAL (Write-Ahead Log) для обеспечения транзакционной целостности. При установке synchronous_commit = off изменения сначала фиксируются в WAL-буфере в оперативной памяти, и СУБД мгновенно подтверждает транзакцию клиенту. Сброс логов на диск происходит асинхронно с задержкой до 50 мс. При аварийном отключении питания сервера могут быть потеряны только те данные, которые были изменены за последние 20–50 мс. База данных при этом не будет повреждена и сохранит логическую целостность, так как при перезапуске PostgreSQL автоматически восстановит согласованное состояние. Для большинства компаний такое минимальное допущение является оправданной ценой за ускорение операций записи в 1С в 3–5 раз.

Какой дистрибутив Linux выбрать для сервера 1С и PostgreSQL: Rocky Linux или Ubuntu Server?

Производительность СУБД на обоих дистрибутивах одинакова при идентичной настройке ядра. Выбор зависит от инфраструктурных стандартов и компетенций администраторов:

• Rocky Linux / RedOS / Astra Linux (семейство RHEL): Стабильные корпоративные дистрибутивы с консервативной пакетной базой и файловой системой XFS из коробки. Рекомендуются для крупных систем с повышенными требованиями к отказоустойчивости и лицензионной поддержке.
• Ubuntu Server (семейство Debian): Проще в установке, содержит более новые версии вспомогательных пакетов в стандартных репозиториях. Оптимален для небольших и средних проектов.

Почему стандартный autovacuum в PostgreSQL не справляется с базой 1С и как это увидеть?

По умолчанию autovacuum запускается только после изменения 20% строк таблицы. В базе 1С таблицы регистров могут содержать миллионы строк. Если в таблице на 10 млн записей накопился 1.9 млн мертвых строк, автовакуум не запустится, так как лимит в 20% не достигнут. При этом СУБД будет вынуждена считывать эти мертвые строки при каждом запросе. Проверить количество мертвых строк можно запросом:

SELECT relname, n_dead_tup, last_vacuum, last_autovacuum FROM pg_stat_user_tables WHERE n_dead_tup > 0;

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

Что лучше для 1С: PostgreSQL или MS SQL Server?

MS SQL Server обладает продвинутым планировщиком запросов, который сглаживает ошибки неоптимального кода 1С без ручной настройки, но стоимость его лицензий крайне высока. PostgreSQL под Linux — это бесплатная альтернатива. При правильной настройке параметров операционной системы, файлов конфигурации СУБД и регулярном обслуживании производительность PostgreSQL не уступает коммерческим аналогам на базах объемом до нескольких терабайт.

Как часто нужно делать REINDEX и чем он отличается от pg_repack?

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

• REINDEX перестраивает индекс с нуля, очищая его от мусора, но блокирует таблицу на запись на время выполнения. Операцию рекомендуется запускать раз в неделю во внерабочее время.
• pg_repack выполняет аналогичную очистку индексов и таблиц в фоновом режиме, используя триггеры для синхронизации изменений, без блокировки пользователей. Это незаменимый инструмент для высоконагруженных систем 24/7.

У нас 1С работает на виртуальных машинах (Proxmox/ESXi). Стоит ли оптимизировать хост или достаточно настроить гостевую ОС?

Оптимизация гостевой ОС не принесет эффекта, если хост виртуализации настроен стандартно. На уровне хоста необходимо:

1. Выполнить жесткую привязку виртуальных процессоров VM к физическим ядрам CPU (CPU pinning) для исключения переключений контекста.
2. Отключить динамическое распределение памяти (Memory Ballooning), зарезервировав весь объем ОЗУ за виртуальной машиной СУБД.
3. Использовать для дисков СУБД тома LVM или raw-устройства вместо файлов виртуальных дисков (qcow2/vmdk) для исключения лишних очередей ввода-вывода.

30-дневный пошаговый план настройки и ускорения PostgreSQL

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

Неделя 1: Сбор базовых метрик и дисковый аудит

• День 1-2: Разверните систему мониторинга (Zabbix или Prometheus + Grafana). Начните сбор метрик загрузки CPU, RAM и дисков (очередь диска, процент утилизации).
• День 3: Выполните замеры производительности 1С в текущем состоянии с помощью теста Гилева или фиксацией времени выполнения ключевых операций по APDEX.
• День 4-5: Проведите низкоуровневые тесты накопителей с помощью fio во внерабочее время. Замерьте показатели IOPS и времени задержки записи. Выполните тест pg_test_fsync.
• Результат: Зафиксированы базовые метрики производительности 1С и реальные возможности дисковой подсистемы.

Неделя 2: Оптимизация операционной системы Linux

• День 6-7: Переведите процессор сервера в режим максимальной производительности (performance). Проверьте тактовые частоты CPU под нагрузкой.
• День 8-9: Внесите изменения параметров виртуальной памяти в /etc/sysctl.conf (vm.swappiness = 1, настройки сброса грязных страниц в байтах). Примените параметры командой sysctl -p.
• День 10: Отключите Transparent Huge Pages (THP) в загрузчике Grub. Настройте дисковый планировщик none для NVMe-накопителей. Добавьте в /etc/fstab опции noatime,nodiratime для разделов баз данных СУБД.
• Результат: Операционная система оптимизирована для работы СУБД, устранены задержки планировщика ядра Linux.

Неделя 3: Настройка параметров PostgreSQL

• День 11-12: Рассчитайте лимиты оперативной памяти shared_buffers, work_mem и temp_buffers под объем ОЗУ вашего сервера. Внесите изменения в файл postgresql.conf.
• День 13-14: Оптимизируйте коэффициенты стоимости планировщика (random_page_cost = 1.1), настройте параметры контрольных точек и отключите синхронную запись транзакций (synchronous_commit = off).
• День 15: Перезапустите службу СУБД PostgreSQL. Проанализируйте логи запуска на отсутствие ошибок. Контролируйте потребление памяти процессами в течение дня.
• Результат: Параметры PostgreSQL адаптированы под ресурсы сервера и структуру запросов 1С.

Неделя 4: Настройка регламентов обслуживания и фиксация результатов

• День 16-17: Сделайте параметры автовакуума более агрессивными в postgresql.conf. Пропишите в планировщик задач cron выполнение ежедневного ночного сбора статистики СУБД (ANALYZE).
• День 18-19: Настройте еженедельную ночную переиндексацию базы данных (REINDEX) по выходным дням. Для баз 24/7 настройте фоновую очистку через pg_repack.
• День 20-21: Выполните повторные замеры скорости 1С с помощью теста Гилева и сравните показатели времени выполнения операций по APDEX с показателями первой недели.
• День 22-30: Проведите тонкую донастройку. Контролируйте логи СУБД на наличие записей о временных файлах (temporary file), точечно увеличивая work_mem при необходимости.
• Результат: Инфраструктура полностью оптимизирована, настроено автоматическое фоновое обслуживание базы данных, зафиксирован рост производительности 1С.