Ускорить сервер 1С без покупки нового железа в большинстве случаев реально. Жалобы пользователей на тормоза почти всегда сначала прилетают к айтишникам, а айтишники, не разобравшись, идут к директору с просьбой докупить процессоры или память. Между этими двумя шагами обычно есть запас в виде настроек: их крутят на трёх уровнях - СУБД, платформа 1С, операционная система и сеть.
Ниже - десять приёмов, которые системный администратор может выполнить сегодня. Все безопасные: переустанавливать сервер не нужно, всё работает на существующей инфраструктуре. В конце - короткий список симптомов, при которых оптимизация уже не помогает и без апгрейда железа не обойтись.
Где обычно находится узкое место в работе 1С
Прежде чем что-то крутить, поймите, во что упёрлись. Нагрузка лежит на четырёх уровнях: процессор (CPU), память (RAM), дисковая подсистема и сеть. Узкое место чаще всего в одном из них, там и нужно работать.
Простые признаки. CPU: процесс rphost постоянно висит на 90–100%. Память: rphost много читает с диска, виден постоянный своп. Диск: high disk queue и длинные ожидания ввода-вывода. Сеть: лаги клиента при низкой загрузке сервера.
Как мерить. В Windows - Performance Monitor плюс счётчики SQL Server. В Linux - vmstat, iostat и sar. На стороне платформы 1С - технологический журнал и журнал регистрации. Если у вас уже есть Zabbix, PRTG или Prometheus, посмотрите счётчики rphost и СУБД оттуда.
И главное правило: оптимизация без замеров «до и после» - это гадание. Зафиксируйте базовую производительность (тест Гилёва, время открытия типового документа, время проведения партионного отчёта), потом крутите. Иначе через неделю вы не вспомните, что именно сработало.
Способы 1–4: оптимизация СУБД
MS SQL: что подкрутить под 1С
Оптимизация ms sql для 1С начинается с двух базовых задач - индексы и память.
Способ 1. Реиндексация и обновление статистики. Фрагментированные индексы - главный убийца скорости 1С на MS SQL. Настройте ночной job в SQL Server Agent: REORGANIZE для индексов с фрагментацией от 5 до 30%, REBUILD выше 30%. Сразу после реиндексации - UPDATE STATISTICS, иначе оптимизатор будет работать по старым данным.
Способ 2. Параметры памяти и tempdb. Задайте Maximum server memory с запасом для ОС, оставьте Min server memory не менее 10–15% от RAM сервера или 2–4 ГБ. tempdb положите на отдельный быстрый NVMe-том и разбейте на несколько data-файлов по числу ядер CPU, но не больше восьми. Это базовая рекомендация Microsoft, для 1С она работает почти всегда.
PostgreSQL для 1С: что подкрутить
Способ 3. Настройка postgresql.conf под объём RAM сервера. Базовые ориентиры: shared_buffers около 25% от RAM, effective_cache_size около 50–75%. work_mem держите небольшим, чтобы не съедало память на каждый сеанс. И обязательно используйте сборки от Postgres Pro или 1С - обычный community PostgreSQL под нагрузку 1С не оптимизирован.
Способ 4. VACUUM и автовакуум. Накопление мёртвых строк в больших таблицах 1С быстро деградирует производительность. Включите автовакуум, для крупных таблиц регистров и журналов задайте более агрессивные autovacuum_vacuum_scale_factor и autovacuum_analyze_scale_factor (типовой ориентир — 0,05 вместо дефолтных 0,2). По расписанию запускайте VACUUM ANALYZE на критических таблицах в окно технических работ.
Способы 5–7: платформа 1С и кластер
Производительность сервера 1С дальше тянут уже на стороне самой платформы - три приёма, которые относительно приемлемы по времени и часто заметно меняют картину.
Способ 5. Регламентные операции 1С - на ночь. Тестирование и исправление, переиндексация информационной базы, реструктуризация при обновлениях - это тяжёлые задачи. Если они идут в рабочее время, пользователи висят. Перенесите их в окно с минимальной нагрузкой через назначенные задания и расписание. Для крупной 1С:ERP это часто и есть главная экономия времени.
Способ 6. Несколько рабочих процессов rphost. Один rphost на всех - узкое место по памяти. Включите «Безопасное расходование памяти» в свойствах рабочего процесса, задайте «Максимум памяти на один сеанс» и «Максимум информационных баз на процесс». Кластер автоматически развернёт нужное число rphost - один зависший сеанс не уронит остальным рабочий день.
Способ 7. Журнал регистрации в SQL вместо SQLite. Формат SQLite по умолчанию - узкое место для крупных баз: на запись возникают блокировки, а открытие журнала за длительный период тормозит. Переведите журнал в формат SQL через консоль администрирования. Эффект заметен сразу: блокировки уходят, журнал листается быстрее.
Способы 8–10: ОС и сетевая обвязка
Что подкрутить в ОС, антивирусе и сети
Настройка ос для 1С - та зона, где админы чаще всего «забывают» три простых вещи и потом удивляются медленной работе.
Способ 8. Исключения антивируса для каталогов 1С и СУБД. Антивирус, проверяющий каждый файл базы на лету, превращает MS SQL в улитку. Добавьте в исключения каталог srvinfo сервера 1С, папки данных и журналов СУБД (data, log, tempdb), исполняемые файлы 1С и SQL Server. Полностью отключать антивирус не нужно и опасно - достаточно точечных исключений.
Способ 9. Режим питания «Высокая производительность». Windows Server и многие сборки Linux по умолчанию работают в сбалансированном режиме - CPU снижает частоту при простое. Для сервера 1С это даёт лаги при пиковой нагрузке. Поставьте «Высокая производительность» в Power Options для Windows или performance governor для Linux. В BIOS отключите агрессивные C-states и Energy Efficient Turbo - 1С чувствительна к латентности процессора.
Способ 10. Сетевые настройки между сервером 1С и СУБД. Если 1С и СУБД на разных машинах, выделите отдельную сеть для трафика между ними, поднимите MTU до Jumbo frames (если оборудование поддерживает) и отключите энергосбережение на сетевой карте. На больших базах разница в скорости отчётов заметна без всяких замеров.
Чего точно не делать
Несколько антипаттернов, которые на форумах встречаются часто и которые портят сервер быстрее любых лагов.
- Не крутите параметры наугад без замеров до и после. Хорошо настроенный параметр под одну нагрузку может ухудшить производительность под другой, без бенчмарка вы этого не увидите.
- Не отключайте антивирус полностью. Достаточно исключить нужные каталоги. Полное отключение - это прямой риск шифровальщика и потеря всей базы. Объяснять руководству, почему данных нет, тяжелее, чем настроить исключения.
- Не удаляйте «лишние» индексы из служебных таблиц 1С. То, что выглядит как мусор, может быть нужно платформе при обновлении конфигурации. После такой «чистки» обновление вылетит с ошибкой в самый неудобный момент.
- Не копируйте значения параметров СУБД из чужих статей без поправки на свой объём RAM и нагрузку. shared_buffers в 16 ГБ на сервере с 32 ГБ RAM - это не «оптимально», это близко к падению по памяти. И не запускайте тестирование и исправление информационной базы в рабочее время, пользователи будут висеть на блокировках весь день, а потом эту историю долго припомнят при каждом ускорении.
Когда оптимизация уже не помогает
Симптомы, при которых дальше тянуть настройки бесполезно - нужен апгрейд железа или серьёзная переработка инфраструктуры.
- Все рабочие процессы rphost постоянно держат CPU около 100%, регламент уже на ночь. Это потолок ядер, нужны более мощные процессоры.
- Объём базы и активная работа уперлись в RAM, своп активен постоянно, добавлять память некуда. Сервер встал в потолок памяти.
- Дисковая подсистема выдаёт длинные ожидания (high IO wait) даже при простаивающем CPU. На SATA SSD стоит крупная база - пора на NVMe или быстрый SAS-массив. И ещё типичная картина: сеть между сервером 1С и СУБД полностью загружена 1 Gb-каналом - пора на 10 Gb.
- Если несколько ресурсов одновременно лежат на пределе и оптимизация уже не помогает - разумнее не подбирать железо наугад, а начать с аудита ИТ-инфраструктуры: он покажет, упёрся сервер в CPU, в память или в диски, и что именно стоит менять.
Заключение
Десять приёмов выше - это бесплатный «тюнинг», который во многих случаях возвращает производительности на приемлемый уровень. Главное правило простое: мерьте до и после, иначе через неделю не вспомните, что именно сработало.
Если все десять пунктов прошли, а пользователи всё равно жалуются на тормоза - проблема в железе, а не в настройках. Когда оптимизация выжата до конца, единственный честный ход посмотреть готовые серверы для 1С под текущее число пользователей и спланировать миграцию вместо ещё одного круга настроек.
