При администрировании серверов 1С:Предприятия, работающих в связке с СУБД PostgreSQL на операционной системе Windows Server, системные администраторы часто сталкиваются с крайне неприятной проблемой. После планового или внепланового перезапуска сервера служба PostgreSQL очень долго (иногда до 30–40 минут) не может запуститься. В это время при попытке пользователей войти в 1С система выдает критическую ошибку: «Сервер БД не обнаружен» или «the database system is starting up».
В этой статье мы подробно разберем, почему возникает эта проблема, проанализируем системные логи, выясним физику процесса записи данных на диск и рассмотрим по шагам эффективные методы решения этой проблемы — от изменения настроек реестра Windows до оптимизации конфигурационных файлов СУБД и аппаратных параметров дискового массива.
Давайте проанализируем лог-файл PostgreSQL, представленный в описании проблемы, чтобы понять внутреннюю логику работы СУБД во время выключения и последующего старта сервера. Рассмотрим записи по шагам:
< 2020-05-09 06:54:30.205 MSK >LOG: received fast shutdown request
< 2020-05-09 06:54:30.205 MSK >LOG: aborting any active transactions
< 2020-05-09 06:54:30.205 MSK >LOG: autovacuum launcher shutting down
В этот момент операционная система Windows завершает свою работу и отправляет службе PostgreSQL сигнал на остановку. СУБД реагирует на него штатно: запускается режим быстрого завершения работы (fast shutdown request), прерываются все активные транзакции пользователей 1С, и останавливается фоновый процесс очистки autovacuum.
После этого СУБД обязана выполнить финальную контрольную точку (shutdown checkpoint). Процесс checkpoint подразумевает, что все измененные данные («грязные страницы»), которые находились в оперативной памяти в буферном кэше shared_buffers, должны быть физически записаны на жесткие диски в файлы табличных пространств. Если база данных 1С имеет большой размер (десятки или сотни гигабайт), а дисковая подсистема перегружена, этот процесс требует значительного времени.
Однако в логе мы видим следующее:
< 2020-05-09 06:59:35.260 MSK >FATAL: the database system is starting up
< 2020-05-09 06:59:35.276 MSK >LOG: database system was interrupted; last known up at 2020-05-09 06:54:38 MSK
Обратите внимание на разницу во времени между отправкой запроса на выключение (06:54:30) и первой записью о запуске (06:59:35). Прошло ровно 5 минут. При этом СУБД рапортует: database system was interrupted (работа системы управления базами данных была прервана).
Это ключевой момент. Операционная система Windows Server, не дождавшись завершения записи всех данных службой PostgreSQL на диск, принудительно «убила» процесс СУБД по таймауту. В результате база данных оказалась в некорректно завершенном состоянии (неконсистентном на физическом уровне).
При последующем старте СУБД обнаруживает эту проблему и начинает процедуру аварийного восстановления (Crash Recovery):
< 2020-05-09 07:32:35.138 MSK >LOG: database system was not properly shut down; automatic recovery in progress
< 2020-05-09 07:32:35.794 MSK >LOG: invalid record length at 188/4A45ED30: wanted 24, got 0
< 2020-05-09 07:32:35.794 MSK >LOG: redo is not required
< 2020-05-09 07:32:36.948 MSK >LOG: MultiXact member wraparound protections are now enabled
< 2020-05-09 07:32:37.042 MSK >LOG: database system is ready to accept connections
СУБД тратит более 30 минут (с 06:59:35 до 07:32:35) на то, чтобы прочитать файлы предзаписи WAL (Write-Ahead Logs), сопоставить их со страницами данных, исправить поврежденные блоки и выполнить накат/откат транзакций. Все это время пользователи 1С получают ошибку подключения, так как СУБД занята самовосстановлением и не принимает внешние соединения.
---
Самый надежный и правильный способ избежать долгого восстановления базы данных — это отказаться от перезагрузки операционной системы «в один клик» через меню «Пуск» или команду shutdown /r без предварительной подготовки. Разберем по шагам безопасный алгоритм остановки сервера:
1C:Enterprise 8.3 Server Agent (имя службы может отличаться в зависимости от версии платформы, например, 1C:Enterprise 8.3 Server Agent (x86-64)). Это гарантирует, что к СУБД больше не будут поступать новые запросы от фоновых заданий или зависших сеансов.services.msc) или через командную строку остановите службу PostgreSQL. Команда в консоли, запущенной от имени администратора, выглядит так:
net stop postgresql-x64-14
postgres.exe полностью исчезли из Диспетчера задач. В этот момент СУБД гарантированно выполнила чистый shutdown checkpoint и записала все данные на диск.Для автоматизации этого процесса мы можем написать простой командный файл (батник) и запускать его при необходимости перезагрузки:
@echo off
echo Остановка службы сервера 1С...
net stop "1C:Enterprise 8.3 Server Agent (x86-64)"
echo Остановка службы PostgreSQL...
net stop "postgresql-x64-14"
echo Ожидание 10 секунд для завершения дисковых операций...
timeout /t 10 /nobreak
echo Выполнение принудительного сброса файлового кэша Windows (опционально)...
sync.exe -e
echo Инициирование перезагрузки сервера...
shutdown /r /t 0
---
Если сервер перезагружается автоматически (например, после установки обновлений Windows Update в ночное время), ручной регламент не поможет. В этом случае нам необходимо настроить саму операционную систему так, чтобы она не убивала службу PostgreSQL раньше времени, а давала ей возможность корректно записать кэш на диски.
По умолчанию в Windows Server таймаут ожидания остановки служб при выключении системы (параметр WaitToKillServiceTimeout) составляет всего от 5 до 12 секунд. Для баз данных объемом более 30 ГБ этого времени критически мало. Нам нужно увеличить этот параметр.
Разберем процесс настройки через реестр:
regedit и нажмите Enter для открытия Редактора реестра.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
WaitToKillServiceTimeout. Если его нет, создайте его.ServicesPipeTimeout и задать ему значение 60000 (60 секунд).Теперь при выключении или перезагрузке Windows Server будет терпеливо ждать до 5–10 минут, давая PostgreSQL возможность полностью выполнить сброс буферного кэша на дисковый накопитель.
---
Мы можем существенно сократить время финальной контрольной точки при остановке СУБД, если правильно настроим параметры записи данных в файле конфигурации postgresql.conf. Разберем ключевые настройки, которые снижают пиковую нагрузку на диски перед выключением.
Откройте файл postgresql.conf (он находится в папке data вашего экземпляра PostgreSQL) и проверьте следующие параметры:
checkpoint_completion_target: Установите значение 0.9. Этот параметр распределяет запись грязных страниц во времени между контрольными точками. При значении 0.9 процесс записи растягивается практически на весь период между чекпоинтами, предотвращая лавинообразную нагрузку на дисковую подсистему и уменьшая количество измененных страниц, которые нужно экстренно сбросить в момент выключения.shared_buffers: Буферный кэш СУБД. На операционной системе Windows для нужд 1С рекомендуется устанавливать этот параметр в пределах 25% от общего объема оперативной памяти сервера (но не более 16–32 ГБ из-за особенностей работы менеджера памяти Windows). Если выделить под shared_buffers слишком много памяти (например, 64 ГБ на сервере с 128 ГБ RAM) при медленных дисках, то объем грязных страниц в памяти будет колоссальным, и СУБД физически не успеет их сбросить за разумное время при выключении.max_wal_size и min_wal_size: Слишком большой размер файлов WAL увеличивает время восстановления СУБД при аварийном завершении работы. Для баз 1С оптимально держать max_wal_size в диапазоне от 4GB до 16GB в зависимости от интенсивности записи транзакций.После изменения параметров обязательно выполните перезапуск службы PostgreSQL или выполните команду перечитывания конфигурации pg_ctl reload.
---
Если длина очереди диска после перезапуска доходит до 10 (как указано в описании проблемы автора темы), это свидетельствует о критическом перегрузе дисковой подсистемы. В штатных условиях на массиве из 4 дисков SAS 15k в RAID10 очередь не должна стабильно держаться на таком высоком уровне. Рассмотрим возможные аппаратные причины медленной работы дисков:
Это одна из самых частых «скрытых» проблем на серверном оборудовании. Аппаратные RAID-контроллеры используют энергонезависимый кэш на запись (Write-Back) для ускорения дисковых операций в десятки раз. Для безопасности данных кэш защищен батарейкой (BBU — Battery Backup Unit) или суперконденсатором с флеш-памятью.
Если батарейка изношена, повреждена или находится в режиме калибровки (Learn Cycle), контроллер в целях предотвращения потери данных при внезапном отключении электричества автоматически переводит режим работы кэша из высокопроизводительного Write-Back (запись в кэш) в крайне медленный Write-Through (прямая запись на диски, минуя кэш).
В режиме Write-Through скорость случайной записи на диски SAS 15k падает лавинообразно. Проверьте состояние RAID-контроллера с помощью специализированных утилит вендора (например, HPE Smart Storage Administrator, Dell MSA CLI или LSI MegaRAID Storage Manager). Если статус батарейки указывает на ошибку, замените ее.
Операционная система Windows активно использует собственный системный кэш для оптимизации работы с файловой системой. Для того чтобы принудительно сбросить все накопленные данные из оперативной памяти Windows на физические накопители перед выключением СУБД, рекомендуется использовать утилиту sync от Марка Руссиновича (Sysinternals). Ее вызов сразу после ручной остановки службы PostgreSQL гарантирует очистку системных кэшей и сократит время выключения сервера.
Использование классических механических жестких дисков (даже быстрых серверных SAS со скоростью вращения шпинделя 15 000 об/мин в массиве RAID10) для баз данных 1С объемом более 30–50 ГБ в современных реалиях не оправдано. Скорость произвольной записи (IOPS) у HDD крайне мала.
Рекомендуется рассмотреть возможность модернизации сервера и переноса баз данных 1С и файлов предзаписи WAL на твердотельные накопители серверного класса (Enterprise SSD с защитой от потери питания PLP) или накопители NVMe. Это позволит сократить время проведения контрольных точек СУБД с десятков минут до нескольких секунд, а процедура аварийного восстановления (если она все же потребуется) будет занимать не более 1–2 минут вместо получаса.