20.01.2026 10:09
PostgreSQL + 1С: как находить тихих убийц производительности
⚡ PostgreSQL + 1С: как находить «тихих убийц» производительности (без DBA и магии)
Иногда всё выглядит идеально:
✅ CPU норм
✅ мониторинг ровный
✅ жалоб нет
✅ slow query log пустой
…а потом наступает закрытие месяца и база начинает “умирать”.
Причина часто не в одном супер-медленном запросе, а в тысячах “почти нормальных” (2–30 секунд), которые суммарно жгут сервер сутками. Это и есть те самые тихие убийцы.
🧰 Что я использовал
- PostgreSQL 14 (сборка от 1С) на Linux
- 1С:Предприятие 8.3
- pgBadger - генератор отчётов по логам Postgres: красиво, наглядно, быстро
✅ Ключевой трюк: логирование “бережно”, но полезно
Чтобы не утонуть в логах, порог ставят не 200 мс, а 3 секунды, и уже потом постепенно снижают.
Пример настройки (идея):
- правильный log_line_prefix (нужен pgBadger)
- lc_messages = 'C' (английский язык сообщений)
- log_temp_files = 0 (ловим временные файлы)
- log_min_duration_statement = 3000 (стартуем аккуратно)
🐴 Реальный кейс: “Троянский конь” из БСП
Запрос уже оптимизировали, но он снова в топе.
Оказалось: после обновления БСП случайно активировали «Разделение данных» → платформа добавила реквизит ОбластьДанныхОсновныеДанные почти во все таблицы → таблицы раздулись, запросы замедлились.
И самый эффективный фикс оказался…
👉 отключить ненужный функционал, а не героически индексировать последствия.
📌 Ссылка на статью: https://habr.com/ru/articles/986306/
✍️ @odin1C_rus
Иногда всё выглядит идеально:
✅ CPU норм
✅ мониторинг ровный
✅ жалоб нет
✅ slow query log пустой
…а потом наступает закрытие месяца и база начинает “умирать”.
Причина часто не в одном супер-медленном запросе, а в тысячах “почти нормальных” (2–30 секунд), которые суммарно жгут сервер сутками. Это и есть те самые тихие убийцы.
🧰 Что я использовал
- PostgreSQL 14 (сборка от 1С) на Linux
- 1С:Предприятие 8.3
- pgBadger - генератор отчётов по логам Postgres: красиво, наглядно, быстро
✅ Ключевой трюк: логирование “бережно”, но полезно
Чтобы не утонуть в логах, порог ставят не 200 мс, а 3 секунды, и уже потом постепенно снижают.
Пример настройки (идея):
- правильный log_line_prefix (нужен pgBadger)
- lc_messages = 'C' (английский язык сообщений)
- log_temp_files = 0 (ловим временные файлы)
- log_min_duration_statement = 3000 (стартуем аккуратно)
🐴 Реальный кейс: “Троянский конь” из БСП
Запрос уже оптимизировали, но он снова в топе.
Оказалось: после обновления БСП случайно активировали «Разделение данных» → платформа добавила реквизит ОбластьДанныхОсновныеДанные почти во все таблицы → таблицы раздулись, запросы замедлились.
И самый эффективный фикс оказался…
👉 отключить ненужный функционал, а не героически индексировать последствия.
📌 Ссылка на статью: https://habr.com/ru/articles/986306/
✍️ @odin1C_rus