← На главную

При настройке СУБД PostgreSQL под требования платформы 1С:Предприятие часто применяются рекомендации из методических материалов ИТС. Однако после внесенных изменений в файл postgresql.conf системные администраторы могут столкнуться со следующей ситуацией: служба PostgreSQL отказывается стартовать, выдавая системное сообщение Windows:

«Служба PostgreSQL на Локальный компьютер была запущена и затем остановлена. Некоторые службы автоматически останавливаются, если они не используются другими службами.»

При этом встроенные журналы СУБД (каталог pg_log или log) часто остаются полностью пустыми и не содержат записей о новых попытках запуска. Рассмотрим подробно причины возникновения этой ошибки и шаг за шагом разберем способы восстановления работоспособности базы данных.

Главная причина: несовместимость параметра effective_io_concurrency в ОС Windows

Проанализируем конфигурационный файл postgresql.conf. Одной из частых причин аварийной остановки службы при старте является параметр effective_io_concurrency.

В методических материалах по оптимизации PostgreSQL для 1С часто советуют включать асинхронный ввод-вывод (например, выставлять значение effective_io_concurrency = 2 или выше). Однако этот параметр опирается на системные вызовы POSIX (posix_fadvise), которые отсутствуют в операционных системах Windows.

В сборках PostgreSQL для Windows данный параметр не поддерживается и должен оставаться равным 1 (или 0 в некоторых версиях), либо быть полностью закомментирован. Если задать значение больше 1, ядро PostgreSQL при инициализации завершает работу с ошибкой еще до того, как успеет открыть собственный журнал логов.

Для исправления ситуации выполним следующие шаги:

1. Откроем файл postgresql.conf в текстовом редакторе.
2. Найдем строку с параметром effective_io_concurrency.
3. Закомментируем ее символом # или установим значение по умолчанию: # effective_io_concurrency = 1
4. Сохраним файл и повторно запустим службу PostgreSQL.

Диагностика сбоев запуска через Журнал событий Windows

Если служба PostgreSQL не записывает данные в собственный лог-файл pg_log, выяснить точную причину можно через штатный системный оснасток Windows. Проанализируем системные логи операционной системы:

1. Нажмем комбинацию клавиш Win + R, введем eventvwr.msc и нажмем Enter.
2. Перейдем в раздел Журналы Windows -> Приложение (Application).
3. Отфильтруем события по источнику PostgreSQL.

В журнале приложений Windows вы увидите точную запись с синтаксической ошибкой или именем некорректного параметра, с указанием номера строки в файле postgresql.conf, из-за которой СУБД не смогла запуститься.

Проверка кодировки файла postgresql.conf (проблема UTF-8 BOM)

Ещё одна распространённая причина падения службы при старте — сохранение файла postgresql.conf в неправильной кодировке. Если редактировать файл через стандартный Блокнот Windows (Notepad), редактор может добавить в начало файла маркер последовательности байтов (BOM — Byte Order Mark).

СУБД PostgreSQL не может распознать символы BOM на первой строке конфигурационного файла, расценивает их как синтаксическую ошибку и немедленно останавливает службу. Чтобы избежать этой проблемы:

• Используйте специализированные редакторы (например, Notepad++ или VS Code).
• Сохраняйте файл строго в кодировке UTF-8 без BOM (UTF-8 w/o BOM) или в кодировке ANSI / ASCII.

Проверка прав доступа к каталогам базы данных

Убедимся, что служба запускается от имени пользователя, имеющего правильные права на каталоги СУБД:

• Учетная запись, от имени которой работает служба (например, postgres или USR1CV8), должна иметь полный доступ к каталогу данных data и всем входящим в него вложенным папкам.
• Пользователь службы не должен быть членом группы Администраторы (Administrator). Из соображений безопасности ядро PostgreSQL может блокировать запуск под учетной записью с администраторскими полномочиями.
• Учетная запись должна обладать локальным правом Вход в качестве службы (SeServiceLogonRight) в политиках безопасности Windows.

Рекомендации по настройке памяти и оптимизации под 1С

При решении проблем с падением базы данных из-за нехватки памяти (ошибки Out of Memory) системные администраторы иногда пытаются принудительно отключить соединение методом слияния, устанавливая параметр enable_mergejoin = off. Разберем, почему это не всегда эффективно и как правильно настроить параметры СУБД:

1. Параметр work_mem: Не следует устанавливать чрезмерно высокие значения work_mem. Этот объем памяти выделяется на каждую операцию сортировки или группировки в рамках каждого запроса. При большом количестве параллельных сеансов 1С суммарное потребление памяти может превысить объем физической ОЗУ сервера. Рассчитывайте work_mem с учетом общего размера оперативной памяти и максимального количества соединений max_connections.
2. Параметр random_page_cost: Чтобы планировщик PostgreSQL оптимально строил планы запросов для 1С на быстрых дисках (SSD / NVMe), вместо отключения отдельных типов соединений рекомендуется снижать стоимость случайного чтения диска:
   Скопировать код

   
   random_page_cost = 1.1–1.5
   seq_page_cost = 1.0
   

3. Параметр max_locks_per_transaction: Платформа 1С активно использует временные таблицы и блокировки. Для стабильной работы рекомендуется увеличить данный параметр до значения 150–250: max_locks_per_transaction = 150

Соблюдение этих правил позволит быстро вернуть службу PostgreSQL в рабочее состояние на операционных системах Windows и обеспечит стабильную работу баз данных 1С:Предприятие.