Оптимизация параметров сервера MS SQL и PostgreSQL для 1С:Предприятие
Архитектура СУБД в связке с 1С и симптомы неоптимальности
Платформа 1С:Предприятие генерирует специфичный SQL-код (через транслятор запросов), который часто является субоптимальным для дефолтных настроек реляционных баз данных. Симптомы неверной настройки СУБД: длительные транзакции, таймауты блокировок (Deadlocks) при проведении документов, 100% утилизация CPU на сервере БД, "распухание" базы и журнала транзакций. Бизнес-риски: парализация работы бухгалтерии в период сдачи отчетности, жалобы пользователей на "зависание" интерфейса.
Сравнение критичных параметров по умолчанию и для 1С
| Параметр СУБД | По умолчанию | Рекомендуется для 1С |
|---|---|---|
MS SQL: Max Degree of Parallelism (MAXDOP) | 0 (Все доступные ядра) | 1 (Отключение параллелизма для предотвращения CXPACKET) |
MS SQL: Cost Threshold for Parallelism | 5 | 50 (Используется, если MAXDOP > 1 для тяжелых отчетов) |
PostgreSQL: shared_buffers | 128MB | 25% - 40% от доступной RAM сервера |
PostgreSQL: row_level_locks | Разные уровни | Платформа 1С берет управление блокировками на себя (Управляемые блокировки) |
Алгоритм тюнинга параметров серверов БД
Сценарий 1: Настройка MS SQL Server
Изменение базовых параметров инстанса через T-SQL для адаптации под логику 1С.
Настройка MAXDOP и Cost Threshold
EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
EXEC sp_configure 'max degree of parallelism', 1; RECONFIGURE;
EXEC sp_configure 'cost threshold for parallelism', 50; RECONFIGURE;
Ограничение памяти (оставляем ОС 4-6 ГБ минимум)
EXEC sp_configure 'max server memory (MB)', 24576; RECONFIGURE;Сценарий 2: Настройка PostgreSQL (postgresql.conf)
PostgreSQL требует обязательной ручной правки конфига. Изменения применяются после рестарта службы.
Базовые параметры для сервера с 32 ГБ RAM и SSD
shared_buffers = 8GB
effective_cache_size = 20GB
maintenance_work_mem = 1GB
work_mem = 64MB
Обязательно для 1С: отключение нестандартного синтаксиса
standard_conforming_strings = on
escape_string_warning = offТиповые ошибки администраторов
- Оставление Auto Shrink включенным в MS SQL: Периодическое сжатие базы катастрофически фрагментирует индексы, что убивает производительность 1С. База должна расти.
- Игнорирование настройки TempDB: В MS SQL базу TempDB необходимо разбивать на несколько файлов данных (по числу ядер ЦП, но не более 8) для устранения конкуренции (PAGELATCH_UP).
Тюнинг СУБД — это лишь 50% успеха. Эксперты ITSTM проведут комплексный аудит, настроят регламентные задания (реиндексация, обновление статистики) и проанализируют технологический журнал 1С для поиска "тяжелых" запросов.
Частые вопросы (FAQ)
Почему 1С рекомендует ставить MAXDOP = 1?
СУБД при параллельном выполнении запроса тратит время на синхронизацию потоков (ожидания CXPACKET). Код 1С (особенно RLS) генерирует сложные запросы, разбиение которых на потоки часто работает медленнее, чем выполнение в одном ядре.
Нужно ли настраивать autovacuum в PostgreSQL для 1С?
Обязательно. Агрессивное обновление записей в 1С быстро накапливает 'мертвые' кортежи (dead tuples). Настройте autovacuum_naptime = 20s и увеличьте autovacuum_max_workers до 4-6.
Какой Recovery Model использовать в MS SQL?
Для продуктивных баз — Full (Полная), с обязательной настройкой ежечасного (или чаще) бэкапа Transaction Log. Если бэкап лога не настроен, журнал разрастется и забьет диск. Для тестовых баз используйте Simple.
Влияет ли версия платформы 1С на настройки СУБД?
Да, начиная с версии 8.3.22, 1С изменила некоторые механизмы работы с PostgreSQL. Всегда сверяйтесь с требованиями ИТС к конкретной версии СУБД (например, патчи 1c-postgresql).