Ситуация, когда на мощном серверном оборудовании формы 1С открываются значительно медленнее, чем на обычном домашнем компьютере или менее производительном сервере, встречается довольно часто. Особенно остро проблема проявляется после аппаратных сбоев или технических работ. Разберем по шагам, как проанализировать эту ситуацию, выявить узкие места и восстановить былую скорость работы системы.
Прежде чем приступать к глубоким настройкам железа и СУБД, необходимо понять, на что именно тратится время. Разберем ситуацию, когда форма открывается за 8–10 секунд вместо ожидаемых 2–3. Проанализируем результаты замера производительности.
Зачастую выясняется, что одна и та же «тяжелая» процедура вызывается с клиента несколько раз при открытии формы. Это может происходить в обработчиках ПриСозданииНаСервере, ПриЧтенииНаСервере или ПриОткрытии. Если код написан неоптимально, каждое обращение к серверу (Server Call) создает задержку, которая суммируется с сетевым пингом и временем выполнения запроса на SQL.
Проанализируем важный момент: если в замере производительности виден только клиентский код, значит, на сервере 1С выключена отладка. Для полноценного анализа необходимо запустить службу сервера 1С с параметром -debug. Только так мы увидим, сколько времени занимает выполнение запросов внутри процедур на стороне сервера.
Рассмотрим ситуацию с точки зрения системного администрирования. Одной из самых частых причин низкой производительности 1С на мощных Xeon-системах являются настройки энергосбережения. Процессоры серверного сегмента по умолчанию стараются экономить энергию, снижая частоту ядер в моменты простоя.
Выясним, как это влияет на 1С: когда пользователь нажимает кнопку открытия формы, сервер получает запрос. Процессору требуется время (микросекунды), чтобы «проснуться» и поднять частоту с базовой до Turbo Boost. Для 1С, работающей по принципу коротких, но интенсивных запросов, эти задержки критичны.
Что необходимо сделать:
Если проблема с производительностью началась после сбоя памяти (например, когда пришлось протирать контакты ластиком), проанализируем физическое состояние системы. Серверные материнские платы критичны к топологии установки планок ОЗУ.
Посмотрим на такие параметры:
Рассмотрим параметры СУБД, которые напрямую влияют на скорость формирования данных для форм 1С. Часто администраторы меняют параметр MAXDOP (Maximum Degree of Parallelism), надеясь на ускорение, но получают обратный эффект.
Для 1С рекомендуется устанавливать MAXDOP = 1. Это гарантирует, что один запрос будет выполняться одним ядром процессора. Почему это важно? При значении 0 (использовать все ядра) SQL Server может попытаться распараллелить даже простой запрос. Время, затраченное на координацию потоков и сборку результата, часто превышает время самого выполнения запроса.
Однако, если вы используете MAXDOP отличный от 1, обратим внимание на параметр Cost Threshold for Parallelism. По умолчанию он равен 5. Для 1С его стоит поднять до 50. Это скажет серверу: «Не пытайся распараллеливать запросы, стоимость которых ниже 50».
Также проанализируем состояние TempDB. При открытии сложных форм 1С часто создает временные таблицы. Выясним следующие моменты:
TempDB должно соответствовать количеству физических ядер (но обычно не более 8).TempDB должны иметь одинаковый начальный размер и одинаковый шаг расширения.TempDB должна располагаться на самом быстром доступном диске (желательно NVMe или SSD).Посмотрим на программную среду. Если сервер не перезагружался долгое время, или наоборот, произошел аварийный перезапуск, кэш 1С и планы запросов SQL могут стать неактуальными.
Разберем необходимые действия по обслуживанию:
srvinfo (за исключением файлов лицензий *.lic и списка баз v8srvlst.lst). Это удалит старые скомпилированные модули, которые могли повредиться при сбое ОЗУ.Выясним, не мешают ли сетевые настройки. Даже если сервер 1С и SQL находятся на одной машине, они взаимодействуют через сетевые протоколы.
Проблема IPv6: По умолчанию Windows приоритезирует IPv6. 1С может пытаться разрешить имя сервера через IPv6, получать тайм-аут и только потом переходить на IPv4. Это добавляет те самые «лишние» секунды при каждом вызове сервера. Рекомендуется либо полностью отключить IPv6, либо настроить приоритет IPv4 через реестр.
Разрешение имен: Проверим, как быстро сервер 1С находит сервер SQL и как терминальный сервер находит сервер приложений. Самый надежный способ исключить влияние DNS — прописать соответствие IP и имен в файле hosts на всех серверах системы.
Чтобы точно понять, где «висят» эти 8 секунд, мы можем настроить технологический журнал (ТЖ) 1С. Рассмотрим минимальный конфиг logcfg.xml для отслеживания долгих серверных вызовов:
<config xmlns="http://v8.1c.ru/7.4/config/log">
<dump location="C:\Dumps" create="false" type="0"/>
<log location="C:\LOG\LongCalls" history="24">
<event>
<eq property="Name" value="CALL"/>
<gt property="Duration" value="1000000"/>
</event>
<property name="all"/>
</log>
</config>
В данном примере мы фиксируем все события CALL (вызовы сервера), длительность которых превышает 1 секунду (1 000 000 микросекунд). Проанализировав полученный лог, мы увидим конкретный метод встроенного языка или SQL-запрос, который вызывает задержку.
Подводя итог, если форма в 1С начала открываться в два раза медленнее после аппаратного сбоя, пройдемся по чек-листу:
MAXDOP = 1 и проверяем файлы TempDB.Комплексный подход к настройке как программной, так и аппаратной части позволит вернуть системе быструю реакцию и обеспечить комфортную работу пользователей.