Ситуация, когда информационная система стабильно работает в течение рабочей недели, но начинает «тормозить» именно в субботу или воскресенье, встречается в практике администрирования 1С довольно часто. Особенность проблемы заключается в том, что обычная перезагрузка сервера и очистка кеша временно решают вопрос, но через неделю ситуация повторяется. В рамках данной статьи мы подробно разберем, какие внутренние и внешние процессы вызывают подобное поведение в 1С:Управление торговлей 11, и выработаем алгоритм устранения этих сбоев.
Первое, на что мы должны обратить внимание, — это стратегия резервного копирования. Зачастую администраторы настраивают инкрементальные или дифференциальные бэкапы в будние дни, а выполнение полного резервного копирования (Full Backup) переносят на выходные. Проанализируем, как это влияет на систему:
Выходные дни традиционно считаются временем с минимальной нагрузкой, поэтому именно на этот период планируются самые тяжелые регламентные операции. Разберем подробнее, что именно может вызывать замедление:
1. Обслуживание индексов и статистики SQL. Рассмотрим ситуацию, когда в плане обслуживания MS SQL Server настроена реиндексация. Если база большая, а дисковая подсистема не справляется с нагрузкой, процесс перестроения индексов может блокировать таблицы и потреблять весь ресурс IOPS. Пока статистика не обновлена или индексы находятся в процессе перестроения, оптимизатор запросов может строить неэффективные планы, что и приводит к жалобам на медленную работу.
2. Внутренние задания УТ 11. В конфигурации Управление торговлей 11 существует множество фоновых заданий. Проанализируем наиболее критичные:
Расчет партий и себестоимости: часто его запускают именно в конце недели для закрытия отчетного периода.Синхронизация данных: если за неделю накопилось много изменений, массовая выгрузка в «Бухгалтерию предприятия» создаст серьезную нагрузку.Обновление агрегатов: для крупных баз этот процесс может быть весьма ресурсоемким.Выясним одну интересную деталь, характерную именно для УТ 11. Рассмотрим механизм подбора товаров. Если сотрудники отдела закупок или маркетинга в пятницу проводят документы УстановкаЦенНоменклатуры с датой начала действия в понедельник (будущей датой), это может привести к деградации производительности. При поиске актуальной цены на текущую дату (выходной день) система вынуждена обрабатывать сложные запросы к регистрам с учетом будущих записей, что в определенных условиях вызывает значительные задержки в форме подбора товара.
Проанализируем работу серверной части 1С. Существует проблема, связанная с тем, что рабочие процессы rphost могут постепенно накапливать ошибки («течь» по памяти) в течение недели. К выходным объем потребляемой памяти достигает критического предела, и сервер начинает использовать файл подкачки (swapping), что на порядки медленнее оперативной памяти.
Посмотрим на настройки кластера серверов 1С. Для предотвращения подобных ситуаций рекомендуется настроить параметры автоматической перезагрузки рабочих процессов:
Допустимый объем памяти — предел, при котором процесс будет помечен как «на замену».Интервал перезапуска — время жизни процесса (например, 86400 секунд для перезапуска раз в сутки).Также стоит учитывать версию платформы. Например, в версии 8.3.27.1859 и смежных были зафиксированы случаи некорректного кэширования метаданных и зависания регламентных заданий. Если ваша версия платформы совпадает с проблемными релизами, стоит рассмотреть возможность обновления или отката на более стабильную сборку.
Если ваш сервер 1С работает в виртуальной среде (VMware, Hyper-V), разберем влияние снимков (Snapshots). Часто бэкап виртуальных машин в выходные сопровождается созданием и последующим удалением (консолидацией) снимков. Процесс объединения дисков в воскресенье может вызвать «stunning» (замирание) виртуальной машины, что пользователи воспринимают как полную остановку системы.
Не забудем и про антивирусное ПО. Посмотрим на расписание полной проверки системы. Если полное сканирование всех дисков сервера назначено на субботу, оно неизбежно вступит в конфликт за ресурсы с процессами sqlservr.exe и rphost.exe.
Чтобы не просто перезагружать сервер, а найти корень проблемы, выполним следующие шаги:
Для детального анализа создадим файл logcfg.xml, который позволит нам увидеть, какие именно запросы выполняются долго. Нас интересуют события DBMSSQL и SDBL с длительностью более 10-20 секунд:
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<dump location="C:\Dumps" create="false" />
<log location="C:\Logs\SlowQueries" history="24">
<event>
<eq property="Name" value="DBMSSQL"/>
<gt property="Duration" value="10000000"/>
</event>
<event>
<eq property="Name" value="SDBL"/>
<gt property="Duration" value="10000000"/>
</event>
<property name="All"/>
</log>
</config>
В моменты замедления работы откроем Activity Monitor в SQL Server Management Studio. Проанализируем разделы Processes и Recent Expensive Queries. Если мы видим процессы с типом ожидания PAGEIOLATCH_EX или RESOURCE_SEMAPHORE, это явный признак проблем с дисками или нехватки оперативной памяти для кэша SQL.
Зайдем в раздел Обслуживание — Регламентные операции — Регламентные и фоновые задания. Отфильтруем задания, выполнявшиеся в субботу и воскресенье. Обратим внимание на длительность выполнения заданий:
ИзвлечениеТекста (если в базе много файлов);ОбновлениеПолнотекстовогоИндекса;СинхронизацияДанных.На основе проведенного анализа внесем корректировки в работу системы:
Таким образом, системный подход к анализу всех слоев системы — от кода 1С до физических дисков — позволит нам устранить периодические сбои и обеспечить стабильную работу УТ 11 в любой день недели.