Закрытие месяца идёт часами, отчёты «висят», пользователи жалуются. Разбираем оптимизацию по слоям: железо, СУБД, регламент, код – без маркетинга.
Сначала диагностика, потом оптимизация
Без замеров оптимизация превращается в гадание. Сначала измеряем – где именно тормозит, потом точечно лечим.
Главная ошибка – начинать оптимизацию с покупки железа или «удаления неиспользуемых пользователей». В половине случаев проблема в настройках СУБД или одном тяжёлом отчёте.
Инструменты диагностики 1С
Замер производительности в Конфигураторе – Меню Отладка → Замер производительности. Включить, повторить медленную операцию, выключить, посмотреть результат – видно, какие именно строки кода и запросы занимают время.
Технологический журнал (logcfg.xml) – Файл logcfg.xml кладётся в каталог conf платформы. Записывает все SDBL/DBMSSQL/EXCP события. Включать только для расследования – лог-файлы быстро разрастаются.
Журнал регистрации 1С – Конфигуратор → Администрирование → Журнал регистрации. Можно отсортировать по длительности транзакций, найти самые долгие операции пользователей.
Мониторинг СУБД – PostgreSQL: pg_stat_statements, pg_stat_activity, pgBadger по логам. MS SQL: Profiler, DMV-запросы. Показывают самые тяжёлые запросы и блокировки на уровне СУБД.
Сервис «Центр контроля производительности» 1С – В составе БСП 3.1+. Замеряет ключевые операции (открытие списка, проведение, ОСВ) по расписанию и хранит динамику.
Пошаговая оптимизация: от быстрых побед к серьёзным
Действуем по принципу «дёшево и быстро → дорого и долго». 70% эффекта обычно даёт первая половина списка.
Бэкап перед любыми изменениями – Полный pg_dump (или backup MSSQL) перед любой настройкой СУБД, перед реструктуризацией, перед обновлением статистики. Часть операций блокирующие – нужна точка отката.
Тестирование и исправление в Конфигураторе – Конфигуратор → Администрирование → Тестирование и исправление информационной базы. Запустить с галками «Реиндексация таблиц», «Проверка логической целостности», «Пересчёт итогов». На больших базах делать в нерабочее время, операция блокирующая.
Обновление статистики и реструктуризация СУБД – PostgreSQL: VACUUM ANALYZE раз в неделю автоматически, VACUUM FULL раз в полгода для удаления «мёртвых» строк (блокирующая, в downtime). MS SQL: UPDATE STATISTICS, REORGANIZE/REBUILD индексов при фрагментации > 30%.
Тюнинг параметров PostgreSQL под 1С – shared_buffers ≈ 25% RAM, work_mem 64–256 MB (зависит от max_connections), effective_cache_size ≈ 75% RAM, max_connections 200–500, autovacuum_max_workers 4–8, checkpoint_timeout 15min. Готовые конфиги под 1С есть на gilev.ru – берите их за основу, не «по умолчанию».
Настройка рабочих процессов сервера 1С – В консоли кластера → Свойства рабочего сервера. Для нагруженных баз – 8–16 рабочих процессов, 4–8 GB RAM на процесс. По умолчанию параметры консервативные.
Регламентные задания: расписание и оптимизация – Тяжёлые регламентки (обновление полнотекстового поиска, расчёт показателей) переносить на ночь. Закрытие месяца – выполнять по партиям (отдельно подразделениями/юрлицами), отключать неактуальные операции (например, переоценка валютных остатков, если нет валютных операций).
Добавление индексов под нетиповые запросы – Если в конфигурации есть нетиповые отчёты с поиском по реквизитам, не входящим в стандартные индексы 1С – добавить «Индексировать» в свойствах реквизита справочника/документа (с условием или без). После реструктуризации запросы ускоряются в разы.
Оптимизация кода нетиповых обработок – Через замер производительности находим самые тяжёлые куски нетипового кода. Типовые проблемы: запрос в цикле (вынести наружу), обращение через `.` к ссылке (предварительно получить через запрос), отсутствие виртуальных таблиц регистров.
Аппаратное усиление – только если СУБД упирается – Если шаги выше не дали эффекта и СУБД-мониторинг показывает упор в IOPS или RAM – апгрейд железа. NVMe SSD вместо SAS, увеличение RAM, при необходимости – отдельный сервер под СУБД.
Перед реструктуризацией и VACUUM FULL – бэкап. Эти операции переписывают физические таблицы и могут оставить базу в неконсистентном состоянии при сбое питания или ошибке. Бэкап pg_dump непосредственно перед операцией – обязателен. На больших базах планировать downtime.
Типичные мифы и красные тряпки
На рынке много «оптимизаторов», которые продают сомнительные услуги. Что НЕ работает или работает на коротком плече.
«Удалим неиспользуемые регистры – ускорим» – Маркетинг. Регистры, к которым нет запросов, не замедляют систему. Удаление освобождает место, но на скорость операций не влияет.
«Купите SSD – всё полетит» – Полу-правда. SSD действительно ускоряет 1С на дисково-зависимых операциях. Но если СУБД настроена плохо или есть запросы в цикле – SSD не спасёт.
«Отключим логи – будет быстрее» – Отключение журнала регистрации даёт 5–10% при интенсивной записи. Но теряется аудит. Лучше – настроить ротацию и архивирование журнала, а не отключать.
«Перенесём базу на SSD-флешку для tempdb» – USB-флешки имеют низкий IOPS на запись и быстро деградируют. Для tempdb MSSQL и временных таблиц PostgreSQL нужен NVMe SSD на сервере, а не флешка.
«Свёртка базы решит все проблемы» – Свёртка убирает старые движения регистров, уменьшает размер базы. Помогает, если база разрослась за 10+ лет. Но не решает проблем настройки СУБД или плохого кода – это инструмент уменьшения, не ускорения.
Когда стоит звать специалиста
Сами справитесь с настройкой СУБД и регламента по готовым конфигам. Дальше – нужны компетенции.
База больше 100 ГБ – Большие базы требуют опыта работы с pg_repack, partitioning, продвинутыми бэкап-стратегиями.
Тормозят нетиповые отчёты и обработки – Аудит кода и переписывание тяжёлых запросов – это компетенция эксперта по платформе 1С, не админа.
Много пользователей и блокировки – Анализ блокировок на регистрах через техжурнал, проектирование управляемых блокировок – требует глубокого опыта.
ERP / УПП с длительной историей – Тяжёлые отраслевые конфигурации требуют узкоспециализированного оптимизатора с опытом именно ERP/УПП.
После всех шагов всё ещё тормозит – Если базовый чек-лист не дал эффекта – нужен аудит с замерами и репортом, что именно упирается. Это полноценный проект на 2–4 недели.
Сначала диагностика, потом оптимизация
См. структурированный premium-вариант выше.
Пошаговая оптимизация: от быстрых побед к серьёзным
См. структурированный premium-вариант выше.
Типичные мифы и красные тряпки
См. структурированный premium-вариант выше.
Когда стоит звать специалиста
См. структурированный premium-вариант выше.
Часто задаваемые вопросы
Сколько RAM нужно серверу 1С для 30 пользователей?
Ориентировочная формула: ~1 GB на каждого активного пользователя 1С + объём под СУБД (shared_buffers + кэши) + ОС. Для 30 пользователей на типовых конфигурациях БП 3 + УТ 11.5: 30 GB на пользователей + 16–32 GB на СУБД + 4 GB на ОС = минимум 50–66 GB RAM, рекомендуется 64–128 GB для запаса на пиковые нагрузки (закрытие месяца, отчётность). На 32 GB будет работать, но при пиках возможны тормоза. В 2026 экономить на RAM смысла нет – 64 GB DDR4 ECC стоят 35–60 тыс. ₽.
Почему 1С тормозит при работе 10 пользователей одновременно?
Чаще всего одна из причин (в порядке частоты): 1) Файловая версия вместо клиент-серверной – файловая не рассчитана на конкурентный доступ, надо переходить на серверный режим. 2) Узкое место в СУБД – мало RAM, медленный диск, дефолтные настройки PostgreSQL/MSSQL. 3) Блокировки – пользователи мешают друг другу на регистрах из-за неоптимального кода. 4) Долгие фоновые задачи конкурируют за ресурсы. 5) Антивирус сканирует директорию СУБД. 6) Сеть Wi-Fi вместо проводной для офисных клиентов. Начинать с диагностики, а не с покупки железа – в половине случаев проблема в настройках.
Стоит ли использовать виртуализацию для сервера 1С?
Для малого бизнеса (5–20 пользователей) – да, потери производительности 5–15% не критичны, зато удобство в управлении (миграции, снапшоты, бэкапы). Для среднего (20–100 пользователей) – да, но с правильной настройкой: фиксированная RAM без overcommit, pinned CPU cores, дисковое хранилище с прямым доступом. Для крупного (100+ пользователей) – часто оправдано вынести СУБД на физический сервер, а сервер 1С:Предприятие держать на виртуалке. Облако (Yandex Cloud, Selectel) – это всегда виртуализация и она работает хорошо при правильной конфигурации.
Помогает ли свёртка базы ускорить 1С?
Помогает в одном конкретном случае: база разрослась за много лет работы, в регистрах накопились движения за 5–10+ лет, размер базы перевалил за 50–100 ГБ. Свёртка убирает старые движения и оставляет только агрегированные остатки на дату – размер базы падает в 2–5 раз, операции ускоряются. НО: после свёртки нельзя построить детализированные отчёты за «свёрнутый» период, нужна архивная копия старой базы. Свёртка не решает проблем плохо настроенной СУБД или тяжёлых нетиповых отчётов – это инструмент уменьшения базы, не общая оптимизация.
Какой бюджет закладывать на оптимизацию 1С?
Зависит от объёма и глубины. Аудит производительности с замерами и отчётом – 50–150 тыс. ₽ (1–2 недели работы). Базовая настройка СУБД и регламентов – 30–100 тыс. ₽ (3–7 дней). Аудит и оптимизация нетипового кода – 100–500 тыс. ₽ в зависимости от объёма доработок. Полный проект «комплексная оптимизация» крупной базы – 500 тыс. – 2 млн ₽. ROI обычно высокий: после нормальной оптимизации операции ускоряются в 2–10 раз, что снижает время простоя пользователей и нагрузку на железо. Хитрость: сначала запросите бесплатную предварительную диагностику – серьёзные подрядчики её делают, чтобы оценить объём работ.