Что мешало стабильной работе системы

Перегрузка регламентных заданий

• обновление кадровых данных;
• перерасчёты начислений;
• синхронизация документов;
• обмены;
• пересчёт итогов;
• очистка временных данных;
• автоматические проверки.

Многие задания запускались параллельно и конкурировали за ресурсы PostgreSQL и блокировки данных.

Большой объём неэффективных доработок

За несколько лет систему дорабатывали разные подрядчики. В результате в конфигурации накопился значительный объём неоптимального кода:

• тяжёлые запросы без индексов;
• циклическая обработка больших наборов данных;
• множественные обращения к регистрам внутри циклов;
• неэффективные СКД-отчёты;
• фоновые обработки без контроля конкурентности;
• избыточные транзакции.

Часть доработок создавалась под локальные задачи без учёта общей нагрузки на систему.

Взаимоблокировки и конкуренция процессов

При одновременной работе пользователей регулярно возникали:

• управляемые блокировки;
• ожидания PostgreSQL;
• взаимоблокировки фоновых заданий;
• очереди на проведение документов.

Особенно часто это происходило в периоды массового расчёта начислений и формирования табелей.

Отсутствие прозрачного мониторинга

До начала проекта компания фактически не имела инструментов объективной диагностики производительности:

• не собирались метрики Apdex;
• отсутствовал централизованный мониторинг;
• не анализировались длительные запросы;
• технологический журнал использовался эпизодически;
• проблемы выявлялись только по жалобам пользователей.

Эксперты по производительности 1С и PostgreSQL

Со стороны исполнителя в проекте участвовали:

• архитектор 1С;
• ведущий разработчик 1С;
• специалист по производительности PostgreSQL;
• DevOps-инженер Linux;
• аналитик бизнес-процессов;
• руководитель проекта.

Со стороны заказчика:

• ИТ-директор;
• руководитель расчётного отдела;
• специалисты кадровой службы;
• внутренний системный администратор Linux/PostgreSQL.

Комплексный анализ производительности системы

Проект начали не с доработок, а с полноценного технического обследования системы.

Какие технологии использовали

Для анализа производительности применялись:

• технологический журнал 1С;
• pg_stat_activity и pg_stat_statements PostgreSQL;
• EXPLAIN ANALYZE для анализа тяжёлых запросов;
• замеры производительности платформы;
• мониторинг фоновых заданий;
• Apdex-анализ пользовательских сценариев;
• анализ блокировок и взаимоблокировок;
• сбор метрик CPU/RAM/IO на Linux-серверах.

Что показал Apdex-анализ пользовательских сценариев

После анализа пользовательских сценариев выявили:

• пики деградации в начале рабочего дня;
• резкий рост ожиданий в дни расчёта зарплаты;
• лавинообразное накопление фоновых заданий;
• падение отклика системы ниже допустимых SLA.

Особенно сильно проседали сценарии:

• открытие списка начислений;
• проведение кадровых приказов;
• расчёт отпусков;
• формирование расчётных листков;
• отчёты по ФОТ.

Критические причины снижения производительности

Конкурирующие фоновые задания

Оказалось, что сразу несколько регламентных процессов запускались одновременно:

• перерасчёт начислений;
• обновление агрегатов;
• расчёт стажа;
• очистка временных данных;
• обмены интеграции.

Все они активно работали с одними и теми же регистрами. В результате PostgreSQL большую часть времени находился не в вычислениях, а в ожиданиях блокировок.

Тяжёлые отчёты

Некоторые отчёты выполнялись десятки минут и создавали колоссальную нагрузку на базу.

Причины:

• отсутствие индексов;
• выборка лишних данных;
• множественные вложенные запросы;
• расчёты внутри СКД;
• обращение к виртуальным таблицам без ограничений.

Один из отчётов по начислениям формировал более 12 миллионов строк промежуточных данных.

Неэффективные механизмы проведения документов

В нескольких доработанных документах были обнаружены:

• длинные транзакции;
• запись регистров внутри циклов;
• повторное чтение данных;
• отсутствие пакетной обработки.

Это приводило к каскадным блокировкам при массовой работе пользователей.

Какие варианты решения рассматривались

Вариант 1. Апгрейд серверной инфраструктуры

Рассматривали:

• увеличение CPU;
• расширение RAM;
• перенос PostgreSQL на более быстрые NVMe SSD;
• масштабирование серверов Linux.

От варианта отказались, поскольку анализ показал: проблема не в нехватке ресурсов, а в неэффективной архитектуре нагрузки.

Вариант 2. Полная переработка доработок

Самый радикальный вариант:

• переписывание всех тяжёлых механизмов;
• отказ от части кастомного функционала;
• переход на новые подсистемы.

• высокий риск;
• длительные сроки;
• большие затраты;
• невозможность быстро стабилизировать систему.

Вариант 3. Точечная оптимизация и стабилизация

Выбранный подход включал:

• устранение критических узких мест;
• оптимизацию тяжёлых запросов PostgreSQL;
• балансировку фоновых процессов;
• снижение конкуренции блокировок;
• внедрение постоянного мониторинга.

Поэтапная стабилизация системы

Этап 1. Стабилизация фоновых процессов

Были переработаны механизмы запуска регламентных заданий:

• часть процессов перевели в последовательное выполнение;
• задания развели по времени;
• ограничили количество параллельных потоков;
• внедрили контроль конкурентного запуска.

Это сразу снизило количество взаимоблокировок.

Этап 2. Оптимизация PostgreSQL-запросов

Провели анализ самых тяжёлых запросов.

Что сделали:

• добавили недостающие индексы;
• переработали JOIN и подзапросы;
• сократили объём читаемых данных;
• убрали лишние временные таблицы;
• оптимизировали обращения к виртуальным таблицам регистров.

Некоторые запросы удалось ускорить в 5–8 раз.

Этап 3. Переработка отчётов

Самые тяжёлые СКД-отчёты были полностью переработаны:

• вынесли предварительные расчёты;
• сократили количество вычисляемых полей;
• изменили структуру выборок;
• добавили кэширование промежуточных данных.

Время формирования отдельных отчётов сократилось более чем вдвое.

Этап 4. Оптимизация обслуживания PostgreSQL

Дополнительно внедрили:

• автоматический VACUUM и ANALYZE;
• обслуживание индексов;
• контроль bloat таблиц;
• регулярную очистку статистики;
• Linux-скрипты обслуживания PostgreSQL;
• автоматический мониторинг роста базы.

Основные сложности проекта

«Плавающие» проблемы

Часть зависаний невозможно было воспроизвести стабильно — они проявлялись только в определённые часы нагрузки.

Для диагностики пришлось:

• собирать длительные трассировки;
• анализировать технологический журнал;
• сопоставлять активность пользователей и фоновых заданий.

Огромное количество старых доработок

Документация по части механизмов отсутствовала полностью.

Некоторые обработки:

• не использовались годами;
• запускались автоматически;
• создавали нагрузку без пользы для бизнеса.

Высокая критичность системы

Производство и расчёт зарплаты нельзя было останавливать.

Все изменения внедрялись:

• поэтапно;
• через тестовый контур;
• с ночными окнами обновлений;
• с обязательным откатом.

Что получили

После завершения проекта система была полностью стабилизирована.

Производительность

• исчезли случайные зависания системы;
• документы начали проводиться без очередей;
• тяжёлые отчёты ускорились до 2 раз;
• сократилось количество блокировок;
• стабилизировалось выполнение фоновых заданий.

Инфраструктура

• нагрузка на PostgreSQL снизилась без апгрейда оборудования;
• CPU в пиковые часы перестал уходить в 100%;
• сократилось количество ожиданий PostgreSQL;
• база стала стабильнее работать при росте пользователей.

Пользовательский эффект

• сотрудники перестали терять время на ожидание;
• расчёт зарплаты стал прогнозируемым;
• исчезли массовые жалобы пользователей;
• кадровые операции начали выполняться стабильно даже в часы пик.

Экономический эффект

Сокращение потерь рабочего времени

За счёт устранения зависаний и ускорения работы системы:

• сокращены потери рабочего времени на 15–20% в пиковые периоды;
• уменьшены простои сотрудников расчётного отдела и HR-службы.

Экономия на инфраструктуре

Удалось избежать дорогостоящего апгрейда серверов:

• предотвращённые затраты: ~1500–2800 тыс. ₽.

Прямой финансовый эффект

За счёт снижения простоев и повышения производительности сотрудников:

• экономический эффект составил ~8–12,5 млн ₽ в год.

Оптимизация без дорогостоящего обновления инфраструктуры

Проект показал, что проблемы производительности в 1С далеко не всегда требуют покупки нового оборудования или полной переработки системы.

Ключевой эффект был достигнут за счёт:

• глубокого технического обследования;
• анализа пользовательских сценариев;
• выявления реальных узких мест;
• оптимизации фоновых процессов;
• устранения блокировок;
• внедрения мониторинга и метрик.

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