При развертывании связки 1С:Предприятие + PostgreSQL на операционной системе Linux технические специалисты часто сталкиваются со следующей проблемой: сразу после перезапуска сервера система работает молниеносно, но через несколько часов или дней производительность лавинообразно падает. Журналы документов открываются по несколько минут, создание элементов справочников зависает, а пользователи жалуются на общую отзывчивость интерфейса. После перезагрузки сервера или служб быстродействие временно восстанавливается.
В этой статье мы подробно проанализируем глубинные технические причины такого поведения, разберем ограничения различных архитектур, дисковой подсистемы, а также рассмотрим пошаговые методы устранения зависаний — от тонкой настройки ядра операционной системы до конфигурации СУБД PostgreSQL и параметров кластера 1С.
Рассмотрим ситуацию, когда на сервере установлено 32-разрядное программное обеспечение (ОС, СУБД и сервер приложений 1С). Даже если мы физически добавим на сервер 8 ГБ, 16 ГБ или более оперативной памяти, 32-битная система не сможет использовать ее эффективно.
Включение ядра с поддержкой PAE (Physical Address Extension) позволяет операционной системе Linux видеть объем ОЗУ более 4 ГБ. Однако для каждого отдельного пользовательского процесса сохраняется жесткое фундаментальное ограничение: процесс физически не способен адресовать более 3–4 ГБ виртуального адресного пространства.
В процессе длительной работы серверное ПО постоянно запрашивает у операционной системы блоки памяти и возвращает их обратно. Со временем возникает явление фрагментации адресного пространства. При фрагментации в пределах выделенного лимита памяти процесса свободные байты распределены хаотично. Когда процессу СУБД или рабочему процессу 1С требуется выделить один непрерывный крупный блок памяти под сложную операцию (например, построение отчета или обработку запроса), операционная система не может найти такой блок в виртуальном пространстве процесса. В результате процесс либо аварийно завершается, либо начинает непрерывно сбрасывать данные в swap-раздел на жестком диске, что приводит к полной потере производительности.
Единственным надежным и системным решением этой проблемы является переход на полную 64-разрядную архитектуру (64-битная ОС Linux, 64-битный PostgreSQL и 64-битный сервер 1С).
Часто системные администраторы отказываются от перехода на 64-битную платформу из-за наличия старого 32-битного аппаратного многопользовательского ключа защиты 1С (HASP). Существует устойчивое заблуждение, что такой ключ не будет работать в 64-разрядной среде.
Выясним, как обойти это ограничение. Мы можем развернуть полноценную 64-битную операционную систему и запустить на ней 64-битный PostgreSQL, а для работы серверной части 1С и аппаратного ключа настроить библиотеки совместимости. Драйвер HASP (служба aksusbd) поставляется разработчиком в 32-битном исполнении, но его можно успешно запустить в 64-битной системе.
Выполним по шагам настройку совместимости в Ubuntu:
sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install libc6:i386 libuuid1:i386 libstdc++6:i386
.deb). После этого служба aksusbd успешно определит наш аппаратный USB-ключ на современной 64-битной системе.Одной из главных причин утренних зависаний и прогрессирующего замедления работы является постепенная утечка памяти в рабочих процессах 1С (rphost). Платформа 1С (особенно старых релизов, таких как 8.3.10) имеет свойство накапливать невысвобожденную память при выполнении сложных запросов пользователей.
Чтобы бороться с этим явлением в автоматическом режиме без регулярных ночных перезагрузок всего сервера, мы можем использовать штатный функционал настройки параметров кластера серверов 1С. Настроим параметры автоматического контроля памяти рабочих процессов:
rphost лимитом порядка 2.5–3 ГБ (2500000 KB - 3000000 KB). Если процесс превысит этот лимит, кластер запустит новый рабочий процесс, а старый пометит как выключаемый.30 или 60 секунд. Это время, в течение которого процесс может кратковременно превышать лимит (например, при формировании тяжелого годового отчета) перед тем, как система примет решение о его замене.60–120 секунд. Данный интервал дает возможность пользователям, чьи сеансы находились на старом процессе, беспрепятственно завершить текущие транзакции и переключиться на новый запущенный процесс rphost. По истечении этого времени старый процесс с утечкой памяти будет принудительно завершен операционной системой, полностью освободив занятые ресурсы.Проанализируем ночную активность сервера. Часто виновником утренних зависаний базы данных является регулярное резервное копирование путем выгрузки информационной базы в файл с расширением .dt. Разворачивание или выгрузка базы объемом всего 350 МБ в формате .dt на протяжении 5 часов — явный признак системного сбоя, вызванного нерациональным использованием ресурсов.
При создании .dt сервер приложений 1С последовательно запрашивает у СУБД абсолютно все таблицы информационной базы, преобразует их во внутренние XML-подобные структуры данных и сжимает в архив. Это создает колоссальную нагрузку на оперативную память процесса rphost. 32-разрядный процесс быстро достигает своего лимита памяти, уходит в бесконечный swap и парализует работу СУБД.
При восстановлении базы из .dt происходит обратный процесс: 1С полностью пересоздает структуру таблиц СУБД, построчно записывает миллионы строк данных и последовательно перестраивает все индексы. На медленных дисках этот процесс генерирует гигантский объем синхронных записей в журнал транзакций СУБД (WAL), блокируя работу дисковой подсистемы.
Рассмотрим правильный подход к резервному копированию на PostgreSQL. Нам необходимо использовать исключительно штатные утилиты резервного копирования СУБД — pg_dump и pg_restore. Они работают напрямую с базой данных в обход сервера приложений 1С, выполняются в десятки раз быстрее и практически не расходуют оперативную память сервера приложений.
Для создания резервной копии базы данных выполним команду в терминале сервера:
pg_dump -U postgres -F c -b -v -f /backup/1c_base_backup.sql base_name
Для восстановления базы данных из созданного бэкапа применим следующую команду:
pg_restore -U postgres -d base_name -v /backup/1c_base_backup.sql
СУБД PostgreSQL крайне чувствительна к скорости работы дисковой подсистемы, а именно к показателю IOPS (количество операций ввода-вывода в секунду) при случайном чтении и записи. Обычный жесткий диск (HDD SATA 7200 RPM) способен выдать максимум 75–100 IOPS. В то же время простейшие твердотельные накопители (SSD) обеспечивают от 50 000 IOPS и выше.
При работе пользователей в 1С генерируется огромное количество временных таблиц (например, при формировании отчетов, расчете себестоимости, поиске в динамических списках). Если размер этих временных таблиц превышает значение конфигурационного параметра PostgreSQL work_mem, СУБД сбрасывает эти данные во временные файлы на диск. На обычном HDD это мгновенно парализует всю работу: дисковая очередь вырастает, а процессы сервера впадают в состояние ожидания ввода-вывода (показатель iowait в мониторинге htop стремится к максимуму).
Рекомендуется перенести базы данных PostgreSQL и временные каталоги СУБД на скоростные SSD или NVMe-накопители корпоративного класса. Это решит проблему с зависанием интерфейсов при одновременной работе нескольких пользователей.
Конфигурация PostgreSQL, сгенерированная стандартными онлайн-генераторами (типа pgtune) без учета специфики платформы 1С, часто упускает из виду критически важные параметры СУБД.
В базах данных 1С происходит постоянная перезапись и удаление информации, из-за чего в PostgreSQL лавинообразно скапливается избыточное количество удаленных версий строк (так называемые "мертвые" строки — dead tuples). Если их вовремя не очищать, таблицы физически раздуваются (bloat), индексы деградируют, а скорость выполнения простейших запросов падает в разы.
Нам необходимо скорректировать настройки планировщика СУБД и процесса автоочистки (autovacuum), сделав его работу более агрессивной. Откроем файл конфигурации СУБД postgresql.conf и внесем следующие изменения:
# Включаем и настраиваем автоочистку
autovacuum = on
autovacuum_max_workers = 4
autovacuum_naptime = 20s
# Очищаем таблицу, если изменилось более 5% строк (по умолчанию 20%)
autovacuum_vacuum_scale_factor = 0.05
# Обновляем статистику планировщика, если изменилось более 2% строк (по умолчанию 10%)
autovacuum_analyze_scale_factor = 0.02
# Настройка стоимости операций для снижения влияния автоочистки на производительность
autovacuum_vacuum_cost_delay = 10ms
autovacuum_vacuum_cost_limit = 1000
Также критически важно использовать сборки PostgreSQL, специально адаптированные под требования 1С (например, от компании Postgres Professional или официальные сборки с сайта 1С). В них интегрированы расширения online_analyze и plantuner. Эти расширения позволяют СУБД моментально пересчитывать статистику по временным таблицам в памяти прямо в момент их создания, что гарантирует построение планировщиком оптимальных и быстрых планов запросов.
Часто при анализе производительности через команду htop системный администратор видит следующую картину: свободной оперативной памяти на сервере еще достаточно, но часть данных процессов уже сброшена в swap-файл (раздел подкачки на диске). Обращение к swap на медленном жестком диске вызывает жесткие фризы всей системы.
Это происходит из-за настроек ядра Linux по умолчанию. Разберем и изменим два критических параметра операционной системы.
Параметр vm.swappiness. По умолчанию в дистрибутивах Ubuntu этот параметр равен 60. Это означает, что ядро Linux начинает превентивно сбрасывать неактивные страницы оперативной памяти в swap, когда занято чуть больше половины объема физической памяти. Для серверов баз данных такое поведение недопустимо. Изменим это значение, заставив ядро использовать swap только в самых крайних случаях (например, при угрозе падения системы по нехватке памяти OOM-killer).
Выполним команду в консоли для временного изменения настройки:
sudo sysctl vm.swappiness=1
Чтобы сохранить настройку после перезагрузки сервера, откроем файл /etc/sysctl.conf и добавим в конец строку:
vm.swappiness = 1
Механизм Transparent Huge Pages (THP). В операционных системах Linux по умолчанию включен механизм прозрачных больших страниц памяти. Он отлично подходит для систем, обрабатывающих последовательные массивы данных. Однако для СУБД PostgreSQL, которая выполняет огромное количество хаотичных и мелких точечных запросов к памяти, данный механизм крайне вреден. Он вызывает задержки при динамическом выделении памяти (процесс memory compaction) и приводит к фрагментации ОЗУ. Его необходимо полностью отключить.
Проверим текущий статус THP в системе:
cat /sys/kernel/mm/transparent_hugepage/enabled
Если в выводе активен параметр [always], отключим его. Для этого добавим в файл /etc/rc.local перед строкой exit 0 следующие команды:
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
После применения всех указанных настроек производительность связки 1С и PostgreSQL на сервере под управлением Linux стабилизируется, прекратятся неконтролируемые утечки памяти, а скорость работы пользователей останется стабильно высокой на протяжении долгого времени аптайма сервера.