В процессе эксплуатации крупных систем на базе 1С:Предприятие 8.3 и MS SQL Server системные администраторы часто сталкиваются с ситуацией, когда производительность системы падает избирательно: у большинства пользователей все работает корректно, а несколько рабочих мест начинают испытывать значительные задержки. В данной статье мы подробно разберем, как локализовать проблему, если «тормоза» возникают периодически, не зависят от мощности клиентского ПК и сопровождаются медленным откликом справочников и форм.
Одной из скрытых причин внезапного падения производительности, как выяснилось в ходе обсуждения, является механизм обновления индекса полнотекстового поиска. В конфигурациях, основанных на старых редакциях (например, «1С:Молокозавод» или «УПП 1.3»), этот механизм может блокировать служебные таблицы или вызывать резкий скачок нагрузки на дисковую подсистему SQL-сервера.
Рассмотрим ситуацию: если вы заметили, что сервер «встает колом» в определенные часы (например, утром или в середине дня), в первую очередь проверьте консоль регламентных заданий. Если в этот момент выполняется «Обновление индекса ППД», попробуйте временно отключить этот механизм для проверки. Программно это можно сделать следующей командой:
ПолнотекстовыйПоиск.УстановитьИспользованиеПоиска(Ложь);
Если поиск необходим пользователям, перенесите выполнение этой операции на ночное время или настройте слияние индексов в периоды минимальной активности. Важно понимать, что на платформе 8.3.10 и выше даже «легкая» операция обновления индекса может вызвать значительные задержки, если база данных имеет большой объем и высокую фрагментацию индексов.
Следующим критическим узлом является временная база данных tempdb. В 1С она используется для хранения временных таблиц, которые создаются практически при каждом сложном запросе или построении отчета. Разберем основные моменты настройки tempdb для SQL Server 2012:
tempdb разделена на несколько файлов данных одинакового размера. Рекомендуется создавать количество файлов, равное числу ядер процессора (но не более 8).-T1117 (равномерное расширение файлов в группе) и -T1118 (выделение полных экстентов). Это минимизирует конкуренцию за страницы распределения (PFS/GAM).tempdb. Как показал опыт, ручной shrink может временно убрать тормоза, но это лишь симптом того, что база забита неэффективными планами запросов или «мусором» от незавершенных транзакций.Если вы наблюдаете, что tempdb не растет в объеме, но система начинает тормозить, проанализируйте запросы на наличие огромных временных таблиц. Один неоптимизированный запрос от одного пользователя может «забить» временное хранилище так, что пострадают все остальные сессии.
Проанализируем события в технологическом журнале. Если вы встречаете записи вида Exception=NetDataExchangeException с описанием Ping time out expired, это явный признак проблем со связью между рабочим местом и сервером приложений 1С. Однако причина не всегда в кабеле.
Разберем, что стоит проверить на сетевом уровне:
rphost.exe, sqlservr.exe и расширения файлов 1С из проверки.Для того чтобы не гадать, а точно знать, что делает сервер в момент тормозов, необходимо настроить Технологический журнал (ТЖ). Создадим файл logcfg.xml в папке conf сервера 1С, который будет фиксировать длительные запросы (более 5 секунд):
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<log location="C:\LOGS\LONG_QUERIES" history="24">
<event>
<eq property="name" value="DBMSSQL"/>
<gt property="duration" value="5000000"/>
</event>
<event>
<eq property="name" value="SDBL"/>
<gt property="duration" value="5000000"/>
</event>
<property name="all"/>
</log>
</config>
Проанализируем результаты: если в логах преобладают события SDBL (уровень прикладных запросов 1С), проблема кроется в коде конфигурации или неоптимизированных выборках. Если же много событий DBMSSQL с длительным временем выполнения, стоит обратить внимание на производительность дисков или блокировки на стороне SQL.
Ситуация, описанная в сообщении №13, очень показательна: один пользователь может запустить обработку, которая «перемолотит» 50 Гб данных. В консоли сервера 1С это можно отследить по колонке «Захвачено СУБД» или «Объем данных». Если вы видите аномально высокие цифры у конкретного сеанса, это может приводить к следующим последствиям:
В таких случаях рекомендуется либо оптимизировать алгоритм обработки (добавить порционность записей), либо настроить автоматический перезапуск рабочих процессов rphost при достижении ими критического объема памяти (например, 4 Гб).
Решение проблем с избирательными тормозами 1С требует комплексного подхода. Мы рассмотрели влияние полнотекстового поиска, специфику настроек tempdb в MS SQL 2012, сетевые настройки и важность анализа технологического журнала. Помните, что перезагрузка сервера или очистка кеша — это временные меры. Только детальный мониторинг через logcfg.xml и настройка SQL-сервера по рекомендациям фирмы «1С» позволят добиться стабильной работы системы.