Признаки медленной 1С — когда пора оптимизировать
Если хотя бы 3 из 6 совпадают — пора оптимизировать (а не покупать сервер):
| Симптом | Норма | Тревога |
|---|---|---|
| Открытие документа реализации | < 2 сек | > 5 сек |
| Проведение документа | < 3 сек | > 10 сек |
| Формирование ОСВ за месяц | < 30 сек | > 2 мин |
| Закрытие месяца | 1–2 часа | 1+ рабочий день |
| Регламентные задания | укладываются в окно | падают по таймауту |
| Конфликт блокировок | < 5/день | 20+/день, операторы видят «ожидание блокировки» |
Дополнительно: база > 30 ГБ, в одной таблице > 4 ГБ (для файлового режима критично — перестаёт открываться).
Базовый разбор причин тормозов — в статье «1С тормозит: 5 причин». Здесь — что конкретно крутить.
20 точек оптимизации — таблица с приоритетами
Сортировка: от «10 минут работы — большой эффект» к «нужен 1С:Эксперт».
| № | Точка | Эффект | Сложность | Когда применять |
|---|---|---|---|---|
| 1 | Очистка журнала регистрации (ЖР) | +5–15% | 30 мин, ИТ | Всегда, особенно если ЖР > 5 ГБ |
| 2 | Отключение детальных событий ЖР | +10–20% | 10 мин, в Конфигураторе | 20+ пользователей |
| 3 | Перенос регламентных заданий на ночь | +20–40% днём | 1 час, без программиста | Всегда. Большинство не настроено |
| 4 | Отключение лишних регламентных | +5–15% | 30 мин | После аудита списка заданий |
| 5 | Тестирование и исправление базы (ТИИ) | +10–30% | 2–6 часов в монопольном | Раз в квартал. Перед обновлением — обязательно |
| 6 | Реиндексация таблиц СУБД (REBUILD INDEX) | +20–50% на отчётах | 1–3 часа, ночью | Раз в месяц при базе > 20 ГБ |
| 7 | Обновление статистики СУБД | +10–25% | 30 мин | Еженедельно. Часто забывают |
| 8 | Обновление платформы 8.3.26+ | +10–30% | 1 день, нужен тест | Если на 8.3.20 и старше |
| 9 | Перевод файловой базы на серверный режим | в 2–5 раз | 1–3 дня | Если пользователей > 5 или база > 5 ГБ |
| 10 | Настройка PostgreSQL (shared_buffers, work_mem) | +20–40% | 1–2 часа | Если PG стоит «из коробки» |
| 11 | Перенос tempdb на SSD (MS SQL) | +15–30% | 1 час | Если tempdb на HDD |
| 12 | Свёртка базы (закрытие старых периодов) | в 2–10 раз | 3–7 дней | База > 50 ГБ, документы > 5 лет |
| 13 | Оптимизация динамических списков | в 5–20 раз для конкретного списка | 4–16 часов программиста | Журналы где «крутится» при открытии |
| 14 | Установка SSD вместо HDD | в 5–15 раз | железо + 4 часа | Любая база на HDD — это смерть |
| 15 | Анализ длительных запросов через ТЖ (DBCALL > 1 сек) | +30–70% на тяжёлых отчётах | 2–5 дней Эксперта | Если есть «вечные» отчёты |
| 16 | Расшивка блокировок (TLOCK, TDEADLOCK) | в десятки раз снижение конфликтов | 5–15 дней Эксперта | Если 5+ конфликтов в день |
| 17 | Реструктуризация v2 (с 8.3.20+) | сокращает окно обновления в 3–4 раза | включить в кластере | При больших базах |
| 18 | Доп. индексы на часто фильтруемые реквизиты | +20–80% на конкретных списках | 1–3 дня | Журналы документов с фильтрами (с 8.3.26 без снятия с поддержки) |
| 19 | Перезапуск rphost по расписанию | стабильность, +10–15% | 30 мин | Серверная база |
| 20 | Переезд в облако с гарантией ресурсов | в 2–4 раза + стабильность | 1–2 дня | Когда сервер на пределе |
С чего начать — первые 5 шагов которые дают +30–50%
Если у вас на руках есть только 1 рабочий день — делайте эти 5 пунктов в таком порядке:
- Чистка журнала регистрации. Конфигуратор → Администрирование → Журнал регистрации → удалить записи старше 30–90 дней. Если ЖР занимает 10+ ГБ — уже здесь почувствуете разгон
- Перенос регламентных на ночь. Особенно «Полнотекстовый поиск» (запускается каждые 2,5 минуты!), «Перепроведение документов», «Обмен данными». Расписания — 23:00–06:00
- Тестирование и исправление. Конфигуратор → Администрирование → Тестирование и исправление. С бэкапом! В монопольном режиме
- Обновление статистики СУБД. Для PostgreSQL:
ANALYZEна всех таблицах. Для MS SQL:UPDATE STATISTICS - Перезапуск кластера 1С. Очистка кэшей, сброс «старых» rphost. На многих серверах rphost накапливают по 10 ГБ памяти за неделю
За 1 день эти 5 шагов дают +30–50% скорости на типичной базе. Без замены железа.
Свёртка базы — когда нужна и что меняется
Что это: программа определяет дату (обычно 1 января), считает остатки на эту дату, делает документ «Ввод остатков», все документы старше — удаляет или помечает. Остаются только остатки + актуальный год.
Когда нужна:
- База > 50 ГБ (для МСБ обычно симптом 5+ лет работы)
- Размер любой таблицы приближается к 4 ГБ (файловый режим — критично, перестаёт открываться)
- Закрытие месяца идёт > 1 дня
- Реструктуризация при обновлении занимает > 8 часов
Что меняется:
- База уменьшается в 3–10 раз (типично с 80 ГБ до 12 ГБ)
- Скорость отчётов растёт пропорционально
- Теряется детализация по старым периодам — отчёт за 2021 год построить уже нельзя
- Сверка с контрагентами по старым периодам — только из архивной копии
Время: от 6 часов до 3 суток (зависит от объёма и СУБД). Обязательно: бэкап, монопольный режим, тестовый прогон.
Альтернатива: оставить «архивную» базу для отчётов прошлых лет и работать в свёрнутой.
Технологический журнал — что смотреть IT-специалисту
ТЖ настраивается через файл logcfg.xml. Включается на ограниченное время (час, день — иначе диск заполнится).
5 событий-маркеров тормозов
| Событие | Что значит | Тревога если |
|---|---|---|
CALL / SCALL | Серверный вызов клиент-сервер | Длительность > 1 сек регулярно |
DBCALL | Запрос к СУБД (с текстом и временем) | > 1 сек, особенно если повторяется |
EXCP | Исключение / ошибка платформы | Любое массовое появление |
TLOCK | Управляемая блокировка — кто, на что, как долго | Длительность > 5 сек |
TDEADLOCK / TTIMEOUT | Дедлок или превышение таймаута | Любое — повод для расследования |
Что искать первым делом:
- Топ-10 DBCALL по длительности — источник тормозов
- Топ-5 TLOCK — кто блокирует и кого
- EXCP вокруг времени жалоб пользователей
Парсить можно: regex, OneScript, готовые конфигурации с Infostart, утилита Гилёва.
Платформа 8.3.X — что нового для производительности
Обновление платформы с 8.3.20 на 8.3.26 — +10–30% производительности «бесплатно». Без переписывания кода. Тестировать обязательно на копии.
- 8.3.24 — уменьшено время первого обращения к большим табличным макетам. Кэш кластерных данных снижает сетевую нагрузку
- 8.3.25 — индексы и уникальные индексы на временных таблицах (ускорение запросов разработчика)
- 8.3.26 (актуальный на апрель 2026) — оптимизация работы сервера на большом числе ядер. Возможность создавать дополнительные индексы для объектов конфигурации без снятия с поддержки. Оптимизация записи событий ТЖ
Настройка PostgreSQL для 1С — ключевые параметры
Для типового сервера 32 ГБ RAM, 50 пользователей. Источник — рекомендации 1С:ИТС.
| Параметр | Значение | Зачем |
|---|---|---|
shared_buffers | 25% от RAM (8 ГБ) | Кэш данных PG. Больше не нужно — ОС сама кэширует |
effective_cache_size | 50–75% RAM (16–24 ГБ) | Подсказка планировщику |
work_mem | 32–128 МБ | Память на сортировку. Мало — пишет на диск, много — OOM |
maintenance_work_mem | 1–2 ГБ | Для VACUUM, CREATE INDEX, REINDEX |
max_connections | по числу активных сессий + 20% | Не «1000 на всякий случай» — каждое соединение ест RAM |
random_page_cost | 1.1 для SSD (по умолчанию 4.0 — для HDD) | Иначе планировщик избегает индексов на SSD |
effective_io_concurrency | 200 для SSD | Параллельные I/O |
Правильная настройка PG даёт +30% производительности на тех же ресурсах. Часто после установки PG стоят дефолтные значения от разработчиков PostgreSQL — они не учитывают специфику 1С.
Сервер vs облако — когда оптимизация уже не помогает
Норма от 1С: 8 ГБ RAM на каждые 100 пользователей сервера 1С. На практике для МСБ с тяжёлыми отчётами — в 2 раза больше.
| Пользователей | RAM (минимум) | RAM (комфорт) | Тип |
|---|---|---|---|
| 2–5 | 4 ГБ | 8 ГБ | Файловый ОК |
| 5–10 | 8 ГБ | 16 ГБ | Файловый или сервер |
| 10–20 | 10 ГБ | 16 ГБ | Только сервер (PG/MSSQL) |
| 20–50 | 16 ГБ | 32 ГБ | Сервер обязательно |
| 50–100 | 32 ГБ | 48 ГБ | Сервер + SSD + балансировка |
| 100+ | 48–64 ГБ | 64–128 ГБ | Кластер 1С, разные базы на разные rphost |
Когда оптимизация уже не помогает (повод в облако):
- RAM использован на 95%+ постоянно
- Диск 100% busy в рабочее время
- CPU 80%+ постоянно при 30 пользователях
- При добавлении 1 пользователя падает производительность всех
Сравнение хостинга — в статье «1С: свой сервер или облако». Наш облачный сервер 1С с гарантией ресурсов — /oblako от 25 000 ₽/мес.
Реальные цифры из практики
Кейс 1: Оптовая торговля, 45 пользователей, УТ 11
- Было: проведение реализации 18 сек, ОСВ 4 минуты
- Сделали: чистка ЖР (15 ГБ → 200 МБ), перенос регламентных на ночь, реиндексация СУБД, обновление платформы 8.3.18 → 8.3.26
- Стало: проведение 4 сек, ОСВ 35 сек
- Срок: 3 дня, без замены сервера
Кейс 2: Производство мебели, 28 пользователей, ERP
- Было: дедлоки 30+ раз в день, закрытие месяца 14 часов
- Сделали: анализ ТЖ (нашли 3 запроса с DBCALL > 8 сек), переписали один отчёт, изменили порядок проведения, настроили PG
- Стало: дедлоков 1–2 в неделю, закрытие месяца 4 часа
- Срок: 8 рабочих дней Эксперта
Кейс 3: Услуги, 15 пользователей, Бухгалтерия 3.0
- Было: база 78 ГБ, открывается 90 сек, отчёты падают по памяти
- Сделали: свёртка базы на 01.01.2024 (78 ГБ → 9 ГБ), реструктуризация v2, остальное по чек-листу
- Стало: открытие 6 сек, отчёты за секунды
- Срок: 5 дней + 1 неделя на проверку остатков
Стоимость оптимизации и сроки
- Базовый чек-лист (пункты 1–7 из таблицы) — 15 000–30 000 ₽, 1–2 дня
- Полный аудит с техжурналом и расшивкой блокировок — 80 000–200 000 ₽, 5–15 рабочих дней
- Свёртка базы — 25 000–60 000 ₽, 3–7 дней
- Перевод на серверный режим (PostgreSQL) — 30 000–80 000 ₽, 1–3 дня
Частые вопросы
Базовый чек-лист (чистка ЖР, регламентные на ночь, ТИИ, обновление статистики) — 15–30 тыс. ₽, 1–2 дня. Полный аудит с техжурналом и расшивкой блокировок — 80–200 тыс. ₽, 5–15 рабочих дней. Свёртка базы — 25–60 тыс. ₽.
Чистку ЖР, перенос регламентных на ночь, ТИИ базы, обновление статистики, перезапуск rphost — может администратор. Всё что глубже (анализ техжурнала, расшивка блокировок, оптимизация запросов) — нужен 1С:Эксперт по технологическим вопросам.
Поможет частично. Главная рекомендация — переход на сервер (PostgreSQL бесплатный). Файловый режим на 25 ГБ — миллисекунды до отказа. Файловая база на сетевой шаре не выдерживает 5+ одновременных пользователей.
Раз в квартал — обязательно. Перед обновлением конфигурации — обязательно. После сбоя питания — сразу. На большой базе ТИИ идёт от 4 до 24 часов.
Если стоит HDD — поможет всегда, в 5–15 раз. Если уже SSD — искать причину глубже (СУБД, блокировки, код, регламентные).
Если CPU/RAM/диск загружены на 80%+ при текущем числе пользователей — упёрлись в железо. Переезд в облако с гарантией ресурсов обычно дешевле и быстрее покупки нового сервера.