Ускоряем 1С на PostgreSQL: от настроек сервера до аппаратных решений

Работа с 1С:Предприятие на базе PostgreSQL часто сталкивается с проблемами производительности: медленные отчёты, долгие проводки, подвисания при одновременной работе пользователей. Причины могут крыться как в неоптимальных настройках СУБД, так и в архитектуре самой конфигурации 1С. Эта статья поможет разобраться, как ускорить 1С на PostgreSQL без покупки нового железа — или с минимальными затратами на апгрейд.

Мы рассмотрим критические параметры PostgreSQL, которые 90% администраторов оставляют по умолчанию, хотя их корректировка даёт прирост скорости в 2–5 раз. Также разберём типичные ошибки в конфигурации 1С, которые тормозят работу с базой, и аппаратные решения для крупных баз (100+ ГБ). Все рекомендации проверены на реальных внедрениях с базами от 50 ГБ до 1 ТБ.

1. Оптимизация конфигурационного файла PostgreSQL

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

• 🔧 shared_buffers — кэш данных в памяти. Рекомендуемое значение: 25% от оперативной памяти сервера (но не более 8 ГБ для 32-битных систем). Пример для сервера с 32 ГБ ОЗУ: shared_buffers = 8GB.
• ⚡ effective_cache_size — оценка общего объёма кэша (ОЗУ + файловая система). Установите 50–75% от ОЗУ, например: effective_cache_size = 16GB.
• 📊 work_mem — память для сортировок и временных таблиц. Для 1С оптимально 16–64 МБ (зависит от сложности отчётов). Пример: work_mem = 32MB.
• 🔄 maintenance_work_mem — память для операций обслуживания (VACUUM, CREATE INDEX). Минимальное значение: 512MB, для больших баз — 1–2GB.

После изменений обязательно перезапустите службу PostgreSQL:

sudo systemctl restart postgresql

⚠️ Внимание: Не устанавливайте shared_buffers более 8 ГБ на 32-битных системах — это приведёт к сбоям. Для 64-битных ограничение снимается, но значения выше 16 ГБ требуют тестирования на вашей нагрузке.

Увеличить shared_buffers до 25% ОЗУ|

Настроить effective_cache_size на 50–75% ОЗУ|

Установить work_mem в 16–64 МБ|

Проверить maintenance_work_mem (минимум 512 МБ)|

Перезапустить службу PostgreSQL-->

2. Настройка автоочистки (autovacuum) для 1С

PostgreSQL использует механизм MVCC (Multi-Version Concurrency Control), который со временем заполняет таблицы "мусором" — устаревшими версиями строк. Если не настроить автоочистку (autovacuum), база будет разрастаться, а запросы — замедляться.

Для 1С критично настроить следующие параметры в postgresql.conf:

Для крупных баз (100+ ГБ) дополнительно настройте autovacuum_vacuum_cost_delay — уменьшение этого параметра ускорит очистку, но увеличит нагрузку на диск. Оптимальное значение: 10–20 мс (по умолчанию 20).

⚠️ Внимание: После изменений параметров autovacuum следите за нагрузкой на диск в пиковые часы. Если I/O нагрузка превышает 80%, верните autovacuum_vacuum_cost_limit к значению 500–1000.

Никогда|Раз в месяц|Раз в квартал|Только при критичных замедлениях|Не знаю, что это-->

3. Оптимизация индексов для типичных запросов 1С

1С генерирует большое количество запросов с фильтрацией по полям Ссылка, Дата, ПометкаУдаления. Если индексы на этих полях отсутствуют, PostgreSQL вынужден сканировать всю таблицу (Seq Scan), что тормозит работу.

Проверьте наличие индексов для ключевых таблиц:

-- Пример создания индекса для таблицы документов
CREATE INDEX idx_doc_date ON _Document123 (Date DESC);
CREATE INDEX idx_doc_ref ON _Document123 (Ref);
CREATE INDEX idx_doc_deletionmark ON _Document123 (DeletionMark);

Для анализа текущих индексов используйте запрос:

SELECT schemaname, tablename, indexname, idx_scan
FROM pg_stat_user_indexes
ORDER BY idx_scan DESC;

• 📅 Индексы по датам (Date) должны быть кластеризованными (используйте CLUSTER после создания индекса).
• 🔗 Для полей Ссылка (Ref) используйте индексы типа HASH — они быстрее для точных совпадений.
• 🗑️ Индексы на ПометкаУдаления (DeletionMark) ускоряют запросы с фильтром "Не помечен на удаление".

4. Аппаратные решения: SSD, ОЗУ и CPU

Если программные методы не дают достаточного прироста скорости, рассмотрите апгрейд железа. Для 1С на PostgreSQL критичны:

• 💾 Дисковая подсистема: Замените HDD на NVMe SSD (например, Samsung 980 Pro или Intel Optane). Для баз >100 ГБ используйте RAID 10 из 4 SSD.
• 🖥️ Оперативная память: Минимальный объём — 16 ГБ для баз до 50 ГБ, 32–64 ГБ для баз 100–500 ГБ. Правило: ОЗУ должно вмещать shared_buffers + кэш ОС + рабочие нагрузки 1С.
• ⚙️ Процессор: Для 1С важнее количество ядер, чем частота. Оптимально: Intel Xeon E5-26xx или AMD EPYC с 8+ ядрами. Избегайте процессоров с низким IPC (например, Intel Atom).

Пример конфигурации для базы 200 ГБ с 50 пользователями:

⚠️ Внимание: При использовании виртуальных машин (VMware, Hyper-V) убедитесь, что виртуальные диски настроены как Thick Provision Eager Zeroed — это исключает накладные расходы на динамическое выделение места.

5. Оптимизация запросов 1С: что можно сделать без программиста

Даже без изменения конфигурации 1С можно ускорить работу, если:

1. 📋 Ограничить периоды в отчётах. Вместо "за всё время" используйте диапазоны в 1–3 месяца. Пример: в отчёте "Обороты по счёту" укажите дату начала 01.01.2026 вместо 01.01.2000.
2. 🔄 Отключить ненужные поля в динамических списках. Каждое поле — это дополнительный JOIN или подзапрос.
3. 🗃️ Архивировать старые данные. Перенесите документы старше 3 лет в отдельную базу с помощью обработки "ВыгрузкаЗначенийВФайл".
4. 🛑 Запретить полные перепроведения. В настройках учётной политики отключите опцию "Перепроводить документы при изменении".

Для анализа медленных запросов используйте лог PostgreSQL. Включите логирование в postgresql.conf:

log_min_duration_statement = 1000  # Логировать запросы медленнее 1 секунды
log_line_prefix = '%t [%p]: '       # Формат лога: время + PID процесса

После сбора логов проанализируйте их с помощью утилиты pgBadger:

pgbadger /var/log/postgresql/postgresql-*.log -o report.html

6. Использование пула соединений (PgBouncer)

1С открывает новое соединение с PostgreSQL для каждого пользовательского действия, что создаёт нагрузку на сервер. PgBouncer — легковесный пул соединений, который уменьшает количество физических подключений к базе.

Установка и настройка:

# Установка (Ubuntu/Debian)
sudo apt install pgbouncer

Редактируем конфиг /etc/pgbouncer/pgbouncer.ini
[databases]
db1c = host=127.0.0.1 port=5432 dbname=base1c

[pgbouncer]
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 50

Ключевые параметры:

• 🔄 pool_mode = transaction — соединения возвращаются в пул после каждой транзакции (оптимально для 1С).
• 📊 default_pool_size — количество соединений в пуле. Рассчитывайте как количество пользователей × 2.
• 🚫 ignore_startup_parameters = extra_float_digits — отключает ненужные параметры, которые 1С передаёт при подключении.

После настройки измените строку подключения в 1С на:

СтрокаПодключения = "Srvr=localhost;Ref=base1c;Port=6432;Usr=user;Pwd=pass";

(Порт 6432 — стандартный для PgBouncer.)

7. Регулярное обслуживание базы: VACUUM и REINDEX

Со временем база 1С "зарастает" фрагментированными данными, что замедляет запросы. Регулярное обслуживание включает:

1. 🧹 VACUUM FULL — физически перезаписывает таблицы, удаляя "мусор". Выполняйте раз в 1–3 месяца в нерабочее время:

   VACUUM (VERBOSE, FULL, ANALYZE) _Document123;

2. 🔄 REINDEX — перестроение индексов. Помогает, если индексы фрагментированы:

   REINDEX TABLE _Document123;

3. 📊 ANALYZE — обновление статистики для планировщика запросов:

   ANALYZE VERBOSE _Document123;

Для автоматического обслуживания используйте cron:

0 3   0 /usr/bin/vacuumdb --dbname=base1c --analyze --username=postgres

⚠️ Внимание: VACUUM FULL блокирует таблицы на запись. Для баз >100 ГБ используйте утилиту pg_repack — она работает без блокировок.

8. Альтернативные решения: TimescaleDB и Partitioning

Если база 1С превышает 500 ГБ и содержит много исторических данных, рассмотрите:

• 📅 Partitioning по датам: Разделение крупных таблиц (например, _Document123) на месячные или квартальные части. Пример:

  CREATE TABLE _Document123 (
  id SERIAL,
  date DATE NOT NULL,
  data JSONB
  ) PARTITION BY RANGE (date);

• ⏳ TimescaleDB: Расширение для PostgreSQL, оптимизированное для временных рядов. Подходит для баз с большим количеством документов за длительный период.

Для реализации partitioning потребуется:

1. Создать функцию-триггер в 1С, которая будет распределять данные по партициям.
2. Настроить pg_partman для автоматического создания новых партиций.
3. Обновить запросы 1С, чтобы они использовали PARTITION FOR (RANGE).

Пример создания партиции для 2026 года:

CREATE TABLE _Document123_y2026 PARTITION OF _Document123
FOR VALUES FROM ('2026-01-01') TO ('2026-01-01');

FAQ: Частые вопросы по ускорению 1С на PostgreSQL

EXPLAIN ANALYZE SELECT * FROM _Document123 WHERE Date > '2026-01-01';