Разработчик клянётся, что код оптимальный. Запросы переписаны, индексы на месте, точечных нотаций в циклах нет. Замер производительности показывает: каждая строка кода выполняется быстро. А 1С всё равно тормозит. Документ проводится 8 секунд. Отчёт формируется минуту.
Код действительно в порядке. Проблема под ним — в инфраструктуре. Вот шесть вещей, которые мы проверяем, когда «оптимизировать нечего, а тормозит». Если же тормоза всё-таки в коде — смотрите антипаттерны запросов 1С, которые незаметны на маленьких базах.
Антивирус сканирует файлы 1С
Kaspersky, Dr.Web, Windows Defender — любой антивирус с реалтаймовым сканированием. Каждый раз, когда 1С читает или пишет временный файл, антивирус перехватывает операцию и проверяет файл. На сервере 1С временных файлов — сотни в минуту.
Симптомы: случайные задержки, невоспроизводимые тормоза. Сегодня документ проводится 2 секунды, завтра тот же документ — 12. Нагрузка на CPU не растёт. Дисковая очередь — в норме. Но в Process Monitor видно: антивирусный процесс читает каждый файл, который создаёт rphost.
Решение: добавить в исключения антивируса каталоги 1С. Минимум:
Каталог временных файлов 1С (обычно %TEMP% или отдельная папка, заданная в настройках). Каталоги баз данных SQL Server (*.mdf, *.ldf, *.ndf). Каталог кластера 1С (C:\Program Files\1cv8\srvinfo). Каталог сервера 1С (C:\Program Files\1cv8\8.3.xx.xxxx\bin).
На одном проекте после добавления исключений среднее время проведения документа упало с 6 секунд до 1.5. В четыре раза. Ни одной строки кода не изменили.
Диски: HDD на сервере баз данных
SQL Server живёт за счёт случайного чтения. Индексы, таблицы, tempdb — всё это random I/O. HDD физически ограничен примерно 150 IOPS. SSD — от 10 000 IOPS. Разница в 70 раз.
Проверить просто: Performance Monitor, счётчик Avg. Disk sec/Read. Если больше 10 мс — диск не справляется. Для SSD нормальное значение — меньше 1 мс.
Типичная ситуация: сервер покупали три года назад, поставили RAID-10 на HDD. Тогда база была 5 ГБ и 20 пользователей. Сейчас — 80 ГБ и 60 пользователей. Данные не помещаются в кэш SQL Server, и каждый запрос идёт на диск. HDD не вывозит.
Решение: SSD для баз данных. Не обязательно весь сервер на SSD. Достаточно перенести на SSD файлы данных SQL Server (mdf, ndf) и файл tempdb. Логи транзакций (ldf) можно оставить на HDD — они пишутся последовательно, и для этого HDD подходит.
Если бюджет ограничен — хотя бы tempdb на SSD. Платформа 1С активно использует временные таблицы, и tempdb — самая нагруженная база на сервере.
Оперативная память: SQL Server голодает
SQL Server кэширует данные в памяти. Чем больше памяти — тем больше данных в кэше — тем меньше обращений к диску. При настройке по умолчанию SQL Server захватывает всю доступную память. Звучит жадно, но для производительности это правильно.
Проблема возникает, когда на том же сервере работает сервер 1С (rphost, ragent, rmngr). Два жадных потребителя на одном хосте. SQL Server забрал 12 ГБ из 16. Серверу 1С осталось 2 ГБ (ещё 2 — ОС). Rphost начинает свопиться. Тормоза.
Решение: ограничить SQL Server через sp_configure 'max server memory'. Эмпирическое правило: оставить серверу 1С минимум 4 ГБ + 100 МБ на каждые 10 активных пользователей. Остальное — SQL Server. На сервере с 16 ГБ и 40 пользователями: SQL Server — 10 ГБ, остальное — ОС и 1С.
Лучшее решение — разнести SQL Server и сервер 1С на разные машины. Или хотя бы на разные виртуалки с фиксированными ресурсами.
Сеть: тонкий клиент через VPN
Тонкий клиент 1С общается с сервером по TCP. Протокол чувствителен к задержкам. В локальной сети ping 0.5 мс — идеально. Через VPN между офисами — 15-30 мс. Через интернет — 50+ мс.
Каждое действие в 1С — это серия обменов клиент-сервер. Открытие формы — десятки запросов. Если каждый запрос добавляет 30 мс задержки, открытие формы с 50 запросами растягивается на 1.5 секунды только на сетевых задержках. Плюс время обработки на сервере.
Диагностика: ping до сервера 1С. Если больше 10 мс — пользователь будет чувствовать задержки. Если больше 50 мс — работа станет мучением.
Решения: опубликовать базу через HTTP (веб-клиент или тонкий клиент через веб-сервер). HTTP-соединение мультиплексирует запросы, что снижает влияние задержки. Или использовать RDP/терминальный сервер — пользователь подключается к серверу рядом с базой, а графика передаётся по сети. Графика сжимается лучше, чем данные 1С.
Настройки SQL Server по умолчанию
SQL Server Express — бесплатная версия. Ограничения: 1 ГБ оперативной памяти, 4 ядра, 10 ГБ базы. Для тестовой среды — нормально. Для production с 30 пользователями — катастрофа. 1 ГБ кэша для базы на 20 ГБ — каждый запрос идёт на диск.
Но даже SQL Server Standard с нормальной лицензией нужно настроить. Три параметра, которые меняем всегда:
Max Degree of Parallelism (MAXDOP). По умолчанию — 0 (автоматически). Для 1С рекомендуем 1. Звучит контринтуитивно — зачем ограничивать параллелизм? Потому что запросы 1С обычно короткие, и накладные расходы на параллельное выполнение превышают выигрыш. При MAXDOP > 1 часто видим CXPACKET waits — потоки ждут друг друга.
Cost Threshold for Parallelism. По умолчанию — 5. Поднять до 50. Это порог стоимости запроса, начиная с которого SQL Server рассматривает параллельное выполнение. Для 1С большинство запросов проще этого порога, и они должны выполняться в один поток.
TempDB: количество файлов. По умолчанию — один файл. Для 1С нужно столько файлов, сколько ядер (но не больше 8). Это снижает contention при одновременном создании временных таблиц несколькими сеансами.
Планы обслуживания: нет или неправильные
Индексы фрагментируются. Статистика устаревает. Логи транзакций растут. Без регулярного обслуживания SQL Server деградирует за месяцы.
Минимальный набор:
Реиндексация — раз в неделю, в нерабочее время. ALTER INDEX REORGANIZE для фрагментации 10-30%, ALTER INDEX REBUILD для фрагментации > 30%.
Обновление статистики — ежедневно. UPDATE STATISTICS с FULLSCAN для ключевых таблиц. Устаревшая статистика — причина неоптимальных планов запросов, в том числе при LEFT JOIN с фильтрами в ON-условии. Оптимизатор думает, что в таблице 1000 строк, а там 100 000.
Бэкап логов транзакций — каждые 15-30 минут. Без этого лог растёт неограниченно и может заполнить диск. На одном проекте лог транзакций вырос до 150 ГБ при базе 20 ГБ. Потому что бэкап логов не был настроен.
Проверка целостности — DBCC CHECKDB раз в неделю. Находит повреждения до того, как они станут проблемой.
Чек-лист: что проверить прямо сейчас
Если 1С тормозит и код уже оптимизирован — пройдите по списку:
Антивирус: каталоги 1С и SQL Server в исключениях? Диски: SSD для баз данных и tempdb? Память: SQL Server не отъедает всё? Сеть: ping до сервера меньше 10 мс? SQL Server: MAXDOP = 1, Cost Threshold = 50, TempDB на нескольких файлах? Обслуживание: реиндексация, статистика, бэкап логов?
В половине случаев, когда к нам приходят с «1С тормозит», причина в одном из этих шести пунктов. Не в коде. Не в конфигурации. В железе и настройках, до которых никто не добрался. Для полного решения вопроса рекомендуем также изучить 10 ключевых параметров SQL Server для 1С и настроить APDEX-метрику, чтобы отслеживать производительность в числах, а не ощущениях. Показательный пример комплексной оптимизации — закрытие месяца в 1С:ERP: там инфраструктурные и запросные проблемы решались одновременно.
