От чего зависит скорость сервера 1С и где искать узкое место
Содержание
Производительность сервера 1С упирается в одно из шести мест: частоту процессора, объём памяти, скорость дисков, настройки СУБД, сеть между сервером 1С и СУБД или неудачный код конфигурации. Чаще всего проблема не в «слабом железе вообще», а в одном узком месте. Пока его не нашли, покупка нового сервера может не дать ничего.
Типичный пример: компания ставит 32-ядерный сервер с частотой 2,1 ГГц вместо старого 8-ядерного на 3,8 ГГц, и проведение документов становится медленнее. Причина простая: один серверный вызов 1С выполняется в одном потоке, и для него важна частота ядра, а не их число.
Процессор и оперативная память: что важнее для сервера 1С
Частота ядра против количества ядер
Каждый вызов пользователя (провести документ
, сформировать отчёт) рабочий процесс rphost обрабатывает в одном потоке. Поэтому скорость отдельной операции определяет частота ядра. Количество ядер определяет, сколько пользователей могут работать параллельно без очереди.
Ориентиры для подбора:
- ⚡ Частота — для сервера 1С берите процессоры с базовой частотой от 3 ГГц и высокой частотой в турборежиме. Серверные модели с большим числом медленных ядер хороши для виртуализации, но не для учётной базы.
- 🧮 Ядра — примерно 1 ядро на 8–15 активных пользователей для сервера 1С плюс отдельные ядра под СУБД, если она на той же машине.
- 🔌 План электропитания — в Windows Server включите схему «Высокая производительность». Режим «Сбалансированный» снижает частоту, и на коротких вызовах 1С это заметно.
Сколько памяти нужно
Память нужна двум потребителям: рабочим процессам 1С и СУБД. СУБД держит в памяти кэш страниц базы, и чем больше база помещается в кэш, тем реже идут обращения к диску.
| Компонент | Ориентир по памяти |
|---|---|
| Операционная система | 4 ГБ |
| Сервер 1С | 150–300 МБ на активного пользователя, тяжёлые отчёты больше |
| СУБД | Размер «горячей» части базы; в идеале вся база целиком |
| Запас | 15–20% |
Пример: 40 пользователей, база 60 ГБ. Сервер 1С — 40 × 250 МБ = 10 ГБ. СУБД — хотя бы 32 ГБ под кэш. Плюс 4 ГБ системе. Итого 46 ГБ, с запасом — 64 ГБ.
Признак нехватки памяти — постоянный файл подкачки и высокий показатель чтения с диска при том, что пользователи открывают одни и те же документы.
Сервер 1С на виртуальной машине
Виртуализация удобна, но добавляет свои потери. Виртуальной машине с сервером 1С выделяйте ядра без переподписки: если на хосте 16 физических ядер, а виртуальным машинам роздано 40, рабочие процессы будут ждать своей очереди к процессору. Память тоже резервируйте полностью, без динамического выделения. Иначе гипервизор отберёт её в момент пиковой нагрузки, когда она нужнее всего.
Диски и скорость ввода-вывода
Дисковая подсистема — самая частая причина медленного сервера 1С после памяти. Каждая запись документа — это запись в файлы данных и в журнал транзакций СУБД. На медленном диске проведение ждёт подтверждения записи.
Что ставить
- 💾 SSD или NVMe для файлов базы, журнала транзакций и временной базы СУБД. Обычные HDD для рабочей базы 1С сегодня оправданы только в архиве.
- 📂 Разнесение — журнал транзакций и
tempdb(в MS SQL) лучше держать на отдельных дисках или хотя бы отдельных томах. - 🧱 RAID — для данных подходит RAID 10. RAID 5 и RAID 6 дают штраф на запись, а 1С пишет много.
- 🛡️ Антивирус — исключите из проверки каталоги файлов базы, журналов СУБД и каталог данных кластера 1С (
srvinfo). Проверка каждого обращения к файлам базы съедает до половины скорости.
Как понять, что тормозит диск
Откройте «Монитор ресурсов» Windows или выполните iostat -x 5 в Linux. Смотрите на время отклика:
| Время отклика диска | Оценка |
|---|---|
| до 5 мс | Норма для SSD |
| 5–20 мс | Терпимо, но под нагрузкой будут задержки |
| больше 20 мс | Узкое место, пользователи это ощущают |
Если сервер виртуальный, медленный диск может быть следствием соседей по хранилищу. Смотрите задержки и на уровне гипервизора, а не только внутри гостевой системы.
Настройка СУБД под 1С: MS SQL и PostgreSQL
Даже на быстром железе СУБД с настройками «по умолчанию» работает хуже, чем могла бы. Ниже то, что стоит проверить в первую очередь.
MS SQL Server
- Ограничьте память. Параметр
max server memory— оставьте системе и серверу 1С их долю. Без ограничения SQL Server забирает почти всё и вытесняет рабочие процессы 1С в подкачку. - Параллелизм. Для баз 1С обычно ставят
max degree of parallelism = 1. Короткие транзакции 1С от параллельных планов чаще проигрывают. - Модель восстановления. При
Fullжурнал транзакций растёт, пока не сделана резервная копия журнала. Если копии журнала не делаются, журнал разрастается на десятки гигабайт и тормозит запись. Либо настройте копирование журнала, либо используйтеSimple, если потеря данных между полными копиями допустима. - Автоприращение файлов. Задайте прирост в мегабайтах (например, 512 МБ), а не в процентах. Мелкие частые приращения дают фрагментацию и паузы.
- tempdb. Несколько файлов одинакового размера, обычно по числу ядер, но не больше 8.
-- Пример: ограничить память SQL Server 40 ГБ и выключить параллелизм
EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
EXEC sp_configure 'max server memory (MB)', 40960; RECONFIGURE;
EXEC sp_configure 'max degree of parallelism', 1; RECONFIGURE;
PostgreSQL
Для 1С используют сборки PostgreSQL с патчами для 1С. Главные параметры в postgresql.conf:
| Параметр | Ориентир | Зачем |
|---|---|---|
shared_buffers | 25% памяти, отданной СУБД | Кэш страниц самой СУБД |
effective_cache_size | 50–75% памяти | Подсказка планировщику о кэше ОС |
work_mem | 32–128 МБ | Память на сортировку в одном запросе |
maintenance_work_mem | 512 МБ – 2 ГБ | Ускоряет VACUUM и построение индексов |
max_locks_per_transaction | 256 и выше | 1С создаёт много временных таблиц |
work_mem выделяется на каждую операцию сортировки каждого сеанса. Значение 1 ГБ при 50 пользователях легко исчерпает память сервера.
После изменения shared_buffers нужен перезапуск службы PostgreSQL. Перезапуск оборвёт все сеансы пользователей — делайте его вне рабочего времени.
Сеть и топология кластера серверов 1С
Где ставить СУБД
Сервер 1С обменивается с СУБД очень большим количеством мелких запросов. Здесь важна не ширина канала, а задержка. Каждая лишняя миллисекунда умножается на тысячи запросов при проведении одного документа.
- 🏠 Одна машина — сервер 1С и СУБД на одном хосте. Для MS SQL включите протокол Shared Memory: задержка минимальна. Хороший вариант для баз до 50–80 пользователей.
- 🔗 Разные машины — сеть не медленнее 1 Гбит/с, лучше 10 Гбит/с, без промежуточных маршрутизаторов и межсетевых экранов с инспекцией трафика. Пинг между серверами — меньше 0,3 мс.
Настройки кластера
В консоли администрирования серверов 1С у рабочего сервера есть параметры, которые влияют на скорость:
- Количество ИБ на процесс и количество соединений на процесс — определяют, как пользователи распределяются по рабочим процессам. Если все тяжёлые базы попали в один
rphost, он становится узким местом. - Безопасный расход памяти за один вызов — ограничивает «прожорливый» вызов, чтобы один отчёт не уронил процесс со всеми пользователями.
- Интервал перезапуска рабочих процессов — помогает, если память процессов растёт со временем.
Для крупных систем добавляют второй рабочий сервер в кластер. Это снимает нагрузку по количеству пользователей, но не ускоряет одну тяжёлую операцию — её по-прежнему выполняет одно ядро.
Для просмотра кластера из командной строки служит утилита rac. Например, rac cluster list покажет кластеры, rac session list — сеансы. Остальные команды и параметры смотрите в rac help.
Конфигурация и код: где теряется больше всего времени
Сервер можно разогнать вдвое, но один неудачный запрос в цикле съест весь выигрыш. Если тормозит конкретная операция, а остальное работает нормально, дело почти всегда в коде.
Частые причины в коде
- 🔁 Запросы в цикле — вместо одного запроса по всем строкам документа выполняется по запросу на каждую строку. 500 строк — 500 обращений к СУБД.
- 🔗 Обращение «через точку» —
Документ.Контрагент.ОсновнойДоговор.Валютав цикле тянет объекты целиком. - 🔒 Автоматический режим блокировок — в старых или доработанных конфигурациях он блокирует таблицы целиком. Управляемый режим блокирует только нужные записи.
- 📊 Отбор по неиндексированным полям и виртуальные таблицы без параметров — СУБД читает всю таблицу.
- 🧩 Тяжёлые подписки на события и обработчики при записи, добавленные доработками.
Как найти виновника
- Включите замер производительности в режиме отладки и выполните медленную операцию. Замер покажет строки кода, которые заняли больше всего времени.
- Для запросов используйте технологический журнал: настройте файл
logcfg.xmlна сбор событийDBMSSQLилиDBPOSTGRSс длительностью больше заданного порога. - Проверьте ожидания на блокировках: события
TLOCKиTTIMEOUTв технологическом журнале показывают, кто кого ждёт.
Технологический журнал без отбора по длительности за час набирает гигабайты и сам нагружает диск. Ставьте порог и ограничивайте срок хранения логов.
Мониторинг и регламентные операции
Производительность сервера не настраивают один раз. База растёт, статистика устаревает, индексы фрагментируются. Без регламента скорость падает постепенно, и пользователи замечают это через несколько месяцев.
Что делать регулярно
| Операция | Частота | Зачем |
|---|---|---|
| Обновление статистики | Ежедневно | Планировщик СУБД выбирает правильный план запроса |
| Дефрагментация индексов | Еженедельно | Меньше чтений с диска |
| Перестроение индексов | Ежемесячно или при фрагментации выше 30% | Полное восстановление структуры |
VACUUM ANALYZE (PostgreSQL) | Ежедневно, если автоочистка не справляется | Чистит «мёртвые» строки и обновляет статистику |
| Очистка кэша процедур (MS SQL) | После обновления статистики | Сбрасывает устаревшие планы |
| Резервная копия | Ежедневно | Защита данных, а для Full — контроль журнала |
Перестроение индексов на больших таблицах нагружает диск и может блокировать таблицы. Запускайте его ночью, когда в базе нет пользователей и не работают обмены.
Какие показатели отслеживать
- 📈 Загрузка процессора по ядрам: одно ядро на 100% при общей загрузке 20% — признак тяжёлой однопоточной операции.
- 🧠 Свободная память и активность файла подкачки.
- 💽 Очередь и время отклика дисков.
- ⏳ Ожидания блокировок в базе.
- 🧾 Время ключевых операций — проведение типового документа, открытие частого отчёта. Удобно оценивать по методике APDEX: задать целевое время и считать долю операций, уложившихся в него.
Для быстрой оценки железа без учёта кода используют синтетический тест Гилева. Он не скажет, почему тормозит база, но покажет, слабый ли сервер по сравнению с типовыми результатами.