Закрытие месяца идёт часами, отчёты «висят», пользователи жалуются. Разбираем оптимизацию по слоям: железо, СУБД, регламент, код — без маркетинга.
Сначала диагностика, потом оптимизация
Без замеров оптимизация превращается в гадание. Сначала измеряем — где именно тормозит, потом точечно лечим.
Главная ошибка — начинать оптимизацию с покупки железа или «удаления неиспользуемых пользователей». В половине случаев проблема в настройках СУБД или одном тяжёлом отчёте.
Инструменты диагностики 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 раз, что снижает время простоя пользователей и нагрузку на железо. Хитрость: сначала запросите бесплатную предварительную диагностику — серьёзные подрядчики её делают, чтобы оценить объём работ.