PostgreSQL и Linux для «1С:Предприятие-8»

02.06.25

База данных - Администрирование СУБД

Преимущества использования PostgreSQL как объектно-реляционной СУБД и Linux в качестве операционной системы сервера

     Меня зовут Валерий, разработчик 1С в Programming Store.

 

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

 

Содержание:

1. Вводная часть:  

1.1. PostgreSQL и Linux при развертывании «1С:Предприятия».

1.2. Почему PostgreSQL.

1.3. Почему Linux.

2. Требования.

3. Установка.

4. Особенности настройки.

5. Фишки.

6. Возможные ошибки.

7. Что еще почитать.

 

 

PostgreSQL и Linux при развертывании «1С:Предприятия»

С каждым годом всё больше компаний переходят на использование открытых технологий, особенно в сфере автоматизации бизнеса.

Одним из наиболее популярных решений становится связка PostgreSQL (в качестве СУБД) и Linux (в качестве операционной системы сервера) при развертывании «1С:Предприятия».

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

Единственный минус — более высокие требования к квалификации специалистов по настройке и поддержке сервера СУБД.

 

Почему PostgreSQL

PostgreSQL — это мощная объектно-реляционная СУБД с открытым исходным кодом, которая хорошо подходит для задач «1С:Предприятия».

Основные преимущества:

- совместимость с 1С: с 2011 года PostgreSQL официально поддерживается как рекомендованная СУБД. Используются специальные сборки PostgreSQL от 1С или Postgres Professional;

- производительность: высокая скорость обработки транзакций, конкурентный доступ благодаря MVCC, поддержка больших объёмов данных, гибкая настройка под различные сценарии использования;

- расширяемость: поддержка расширений (pg_stat_statements, auto_explain), интеграция с внешними системами через FDW, REST и другие механизмы.

 

Почему Linux

Использование Linux в связке с PostgreSQL и 1С даёт следующие преимущества:

- надёжность и стабильность: долговременная работа серверов, отказоустойчивость при грамотной настройке RAID, LVM, мониторинга;

- безопасность: гибкая настройка прав, SELinux, встроенные механизмы контроля;

- бесплатность: отсутствие необходимости в лицензиях, возможность использования отечественных дистрибутивов.

 

Требования

- PostgreSQL версии 9.6 или выше. Лучше использовать сборку от 1С или Postgres Professional.

- Поддерживаемые ОС: CentOS, Red Hat, Ubuntu, Debian, РЕД ОС.

- Минимальные системные требования: 8 ГБ ОЗУ, SSD-диски, многоядерный процессор.

Важно: хотя возможна установка PostgreSQL на Windows, для продуктивных систем 1С настоятельно рекомендуется использовать Linux из-за ограничений производительности и работы с большим числом файлов.

 

Установка

Пример установки PostgreSQL на Ubuntu:

1. Добавление репозитория:

   wget https://repo.postgrespro.ru/1c-16/keys/pgpro-repo-add.sh
   sh pgpro-repo-add.sh

2. Установка:

apt install postgrespro-1c-16

3. Проверка локали:

 locale

Должно быть ru_RU.UTF-8

4. Инициализация кластера:
 

 initdb -D /opt/pgpro_data --data-checksums --encoding=UTF8 --locale=ru_RU.UTF-8 --lc-collate=ru_RU.UTF8 --lc-ctype=ru_RU.UTF-8 --lc-messages=C

5. Запуск и автозагрузка:

 systemctl enable --now postgrespro-1c-16

 

 

Особенности настройки

После установки важно правильно настроить PostgreSQL:

- Файл pg_hba.conf (сетевой доступ):

 host all all 192.168.1.0/24 md5

- Основные параметры postgresql.conf:

  shared_buffers = 2GB — кэш СУБД (25–40% от ОЗУ)

  work_mem = 64MB — объём памяти на сортировки (зависит от числа пользователей)

  effective_cache_size = 6GB — размер кэша ОС (50–70% от ОЗУ)

  maintenance_work_mem = 512MB — обслуживание: VACUUM, CREATE INDEX и т. д.

  autovacuum = on — автоматическая очистка таблиц

  max_connections = 200 — максимальное количество подключений

Настройки лучше размещать в конце файла postgresql.conf для удобства. После изменений выполните перезапуск:

sudo service postgresql restart

 

Фишки

- Использовать отдельный инстанс PostgreSQL для каждой базы 1С: это упростит обслуживание и устранение проблем.

- Использовать мониторинг: Prometheus, Grafana, Zabbix, ELK, pg_stat_statements, auto_explain.

- Регулярно делать бэкапы: pg_basebackup, pgBackRest, barman.

- Совместимость с CI/CD-средами: автоматизация развертывания и тестирования.

 

Возможные ошибки

Медленная работа пользователей:

- причины: неработающий autovacuum, нехватка памяти, неэффективные запросы;

- решение: настройка autovacuum, анализ pg_stat_statements и auto_explain.

 

Ошибка подключения из 1С:

- причины: PostgreSQL не запущен, заблокирован порт, неверные учётные данные подключения;

- решение: проверить запущены сервисы и настройки firewall;

 

Ошибка «deadlock detected»:

- причина: ошибка в транзакционной логике в коде 1С;

 

Ошибка «out of shared memory» или «too many clients»:

- причина: превышен max_connections или утечка соединений с внешними клиентскими ПО;

- решение: увеличить лимит и настроить pgbouncer.

 

Резкое увеличение размера базы:

- причины: неэффективный autovacuum, много старых WAL-файлов;

- решение: сделать настройки более «агрессивными», autovacuum_vacuum_threshold, autovacuum_vacuum_scale_factor. Регулярно выполнять VACUUM FULL, REINDEX.

 

Ошибка записи: «could not write to file», «no space left on device»:

- причина: переполнение диска;

- решение: удалить/архивировать старые WAL-файлы, расширить хранилище.

 

Общие рекомендации:

- использовать pg_stat_statements для анализа производительности;

- настроить мониторинг (Grafana, Zabbix);

- использовать пул соединений (pgbouncer);

- проводить регулярное обслуживание  (VACUUM, REINDEX);         

- вести логирование длительных операций (log_min_duration_statement).

 

 

Что еще почитать 

1. Официальный сайт PostgreSQL 

2. Документация Postgres Professional

3. Документация по pg_stat_statements

4. Документация по auto_explain

5. Руководство по Grafana и Prometheus

6. Документация по Zabbix

Вступайте в нашу телеграмм-группу Инфостарт

PostgreSQL СУБД Linux «1С:Предприятия»

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

HighLoad оптимизация Администрирование СУБД Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Бухгалтерский учет Бесплатно (free)

После миграции с MS SQL на PostgreSQL закрытие месяца в 1С:ERP стало идти 8 часов вместо 12 минут. Рассказываем, как мы нашли причину в оценке Hash Join, которую планировщик завышал в миллионы раз, и как исправили её так, что проблемный запрос теперь выполняется за 18 секунд вместо часа.

19.10.2026    939    Tantor    0    

10

Администрирование СУБД HighLoad оптимизация Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

Большинство материалов о компрессии в PostgreSQL отвечают на вопрос «во сколько раз удалось уменьшить базу». Мы предлагаем посмотреть на проблему с другой стороны — какой ценой достигается эта экономия? В статье разбираем архитектурные компромиссы различных подходов к компрессии страниц, объясняем, почему при разработке CSM в Tantor Postgres отказались от погони за максимальным коэффициентом сжатия, и показываем результаты нагрузочных испытаний на реальных базах 1С.

01.10.2026    1440    Tantor    6    

17

HighLoad оптимизация Администрирование СУБД Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Бесплатно (free)

В рамках 18 релиза СУБД Tantor Postgres мы рассказывали об оптимизациях, которые помогают планировщику сделать более точный выбор между Nested Loop и Hash Join. В следующем релизе у нас планируются оптимизации, которые позволят ускорить выполнение как Nested Loop, так и Hash Join. Сегодня мы расскажем об одном из таких методов - фильтре Блума.

31.08.2026    6111    Tantor    3    

18

Администрирование СУБД Системный администратор Разработчик Бесплатно (free)

5,5 тысячи пользователей в единой базе 1С, розница в режиме 24/7 и SLA 99,98% – в таких условиях любая авария быстро превращается в очереди на кассах, потерю денег и давление со стороны бизнеса. Показываем, как выстроить процесс аварийно-восстановительных работ: от первых алертов и базового скрининга системы до подключения команды, проверки гипотез и дебрифа после инцидента. Разбираем, как метрики, дашборды, техжурнал, Zabbix, Prometheus, Grafana, Telegram-боты и скрипты помогают не гадать, а быстро находить причину проблемы. На реальных авариях объясняем, почему «быстро» не должно означать «рискованно», как работа над ошибками снижает панику и почему каждая авария может сделать систему надежнее.

11.08.2026    3400    jul.dolganova    9    

24

Администрирование СУБД 1С 8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

База 1С:ERP размером 646 Гб, полное маскирование за 5 часов - без создания промежуточной незащищенной копии. Разбираем бесплатный pg_anon на сквозном примере с реального продуктива.

27.07.2026    4511    Tantor    16    

17

HighLoad оптимизация Администрирование СУБД Разработчик Россия Бесплатно (free)

Если вы работаете с 1С на PostgreSQL и жалуетесь на тормоза — скорее всего, дело в join predicate pushdown, которого в стандартном PostgreSQL нет. В MS SQL Server этот механизм работает «из коробки», и при миграции именно запросы к виртуальным таблицам 1С бьют по производительности сильнее всего. В этой статье — реальный кейс от Postgres Professional с разбором плана выполнения, ручным экспериментом и доработкой планировщика СУБД, которая ускорила запросы от 22 до 54 000 раз.

16.06.2026    11059    postgres_professional    15    

15
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. SerVer1C 1146 02.06.25 13:33 Сейчас в теме
похоже на рекламный проспект
2. RocKeR_13 1490 02.06.25 13:39 Сейчас в теме
3. paulwist 03.06.25 08:09 Сейчас в теме
Использовать отдельный инстанс PostgreSQL для каждой базы 1С


Нет слов, ... всем "фишкам" фишка :) :) :)

PS я не понял, это плюс или минус ПГ :)
5. starik-2005 3309 03.06.25 13:40 Сейчас в теме
(3)
Нет слов, ... всем "фишкам" фишка :) :) :)
Кстати, чем плохо? По мне так единственная полезная вещь в тексте )))
6. paulwist 03.06.25 15:20 Сейчас в теме
(5)
Кстати, чем плохо? По мне так единственная полезная вещь в тексте )))


Нуу, сегодня на форуме был пост про Restore с 39 БД 1C, те в парадигме ТСа, надо иметь 39 инстансов, ...

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

С точки зрения "работоспособности", говорит, что ПГ не такая уж

PostgreSQL и 1С даёт следующие преимущества:

- надёжность и стабильность:


раз надо страховаться таким способом :)
7. starik-2005 3309 03.06.25 15:38 Сейчас в теме
(6)
те в парадигме ТСа, надо иметь 39 инстансов
Раз у чела столько баз, то, возможно, и система такая, что пару терабайт памяти. А там что один инстанс, что 40 - особой разницы нет в части потоков. Именно из-за этого 1С предлагает ставить параллелизм в мелкомягких скулах в единицу - чтобы на одного юзера один поток был. А раз юзеров много, то и потоков будет столько, сколько юзеров. А разделить инстансы - следующий шаг, где в одном изолированном процессе будут изолированно порождать потоки изолированные юзеры. Ничем не плохо.
8. paulwist 03.06.25 16:05 Сейчас в теме
(7)
А там что один инстанс, что 40 - особой разницы нет в части потоков.


Хех, служебные потоки каждого инстанса не считаем?? :)

(7)
Именно из-за этого 1С предлагает ставить параллелизм в мелкомягких скулах в единицу - чтобы на одного юзера один поток был


Хм, 1С объясняет это по другому, мол при max degree of parallelism = 1 при кривых планах/запросах будут тормоза только у одного юзера, а не у всех одновременно.

(7)
А разделить инстансы - следующий шаг, где в одном изолированном процессе будут изолированно порождать потоки изолированные юзеры.


Видел это для БД с десятками/сотнями млрд записей в таблицах (1 инстанс = 1 БД), либо в OLTP 1000-10000 транзакций в секунду, но это не про 1С.
9. starik-2005 3309 03.06.25 16:27 Сейчас в теме
(8)
служебные потоки
Служебные потоки ща живут, через секунду нет. Они там постоянно флуктуируют, как квантовые эффекты на горизонте событий сферы Шварцшильда.
будут тормоза только у одного юзера, а не у всех одновременно
Ну вот, отличное объяснение. Чем тебе не нравится?
но это не про 1С
Да вообще хайлоад не про 1С. В нее надо уже сгруппированные данные тащить - синтетику, и все будет ОК. Ну если там действительно миллиарды. А если сотни, то и пофиг.
10. paulwist 04.06.25 09:02 Сейчас в теме
(9)
Служебные потоки ща живут, через секунду нет. Они там постоянно флуктуируют, как квантовые эффекты на горизонте событий сферы Шварцшильда.


Что-то мне подсказывает, что 40 инстансов генерят в 40 раз больше потоков чем один инстанс.

(9)
Ну вот, отличное объяснение. Чем тебе не нравится?


Хех, убогостью решения, когда проще запретить, чем дать механизм поддержки правильных индексов, статистик, секционирования итп. НО это к треду не относится :)

(9)
В нее надо уже сгруппированные данные тащить - синтетику, и все будет ОК.


Опять же, будет ОК если

(9)
А если сотни, то и пофиг.
12. RocKeR_13 1490 05.06.25 09:59 Сейчас в теме
(6)
Нуу, сегодня на форуме был пост про Restore с 39 БД 1C, те в парадигме ТСа, надо иметь 39 инстансов, ...

Выше выкладывал весьма полезные видео про PostgreSQL - если посмотрите, то получите исчерпывающий ответ на вопрос о количестве экземпляров Postgre)
4. 2tvad 74 03.06.25 10:06 Сейчас в теме
И в докер разместить или k8s)
11. alexey_kurdyukov 213 05.06.25 05:13 Сейчас в теме
Пишите честно: "использовать постгрес и Линукс нужно потому, что нет вообще никаких альтернатив", вот и всё, это теперь наша печальная реальность.
13. starik-2005 3309 08.10.25 18:50 Сейчас в теме
(11)
печальная
За всех не говори. Когда латыши пилили скайп, то они взяли постгрес и мутнули там 20к rps. У яху была самая большая база для своего времени, она тоже крутилась на постгресе.

Кто не хочет - ищет причины, кто хочет - возможности.
14. alexey_kurdyukov 213 18.10.25 06:31 Сейчас в теме
(13) "расслабься и получай удовольствие"
15. starik-2005 3309 19.10.25 00:36 Сейчас в теме
(14)
"расслабься и получай удовольствие"
Прям еврокомиссия вспоминается с фондерляйн)))
16. alexey_kurdyukov 213 24.10.25 05:32 Сейчас в теме
(15) Не знаю, что такое, не был
17. starik-2005 3309 24.10.25 14:51 Сейчас в теме
(16)
Не знаю
Я тут интереса заради попытался мутнуть с постгресом в скорость на линухе своем, а то уже привык, что у всех там 80+. Ну пошел в гуглы, почитал статьи, и вот, пожалуйста, в линухе постгрес прям вот 100+ набрал.

ЗЫ: у Гилева новый тест. Красивое, но качатеся только с телеги. И да, fsync не отключал.
Прикрепленные файлы:
Для отправки сообщения требуется регистрация/авторизация