Как устранить медленную работу хранилища конфигурации 1С и оптимизировать производительность сервера

Разработчики и системные администраторы часто сталкиваются с ситуацией, когда мощный двухпроцессорный сервер работает медленнее обычного десктопного компьютера. Одним из ярких проявлений этой проблемы является критическое замедление работы с хранилищем конфигурации 1С:Предприятие. Простые действия, такие как захват или помещение объекта, могут занимать до 10 минут, парализуя работу всей команды разработки. Рассмотрим подробно, почему это происходит, как вылечить «болезнь» таблицы DepotFiles и какие аппаратные настройки сервера мешают ему работать в полную силу.

Часть 1. Раздувание таблицы DepotFiles и тормоза хранилища конфигурации

Начиная с версии платформы 1С:Предприятие 8.3.9, архитектура работы с хранилищем конфигурации претерпела изменения. Вместо устаревшей таблицы Files в СУБД MS SQL Server за кэширование файлов конфигурации отвечает таблица DepotFiles. В нормальном режиме работы СУБД количество записей в этой таблице колеблется в пределах от 100 до 300 строк. Однако при возникновении сбоев синхронизации или нарушении регламента обслуживания баз данных количество записей в ней может лавинообразно вырасти до 15 000 и более.

Проанализируем механизм возникновения проблемы. Когда база данных, подключенная к хранилищу, копируется (например, создается тестовая копия базы разработчика) и к ней подключаются без предварительной очистки кэша, платформа теряет соответствие идентификаторов версий. При каждой попытке захвата или обновления конфигурации платформа начинает циклически считывать, записывать и удалять тысячи записей в DepotFiles. В результате простейшая операция захвата одного реквизита начинает требовать колоссальных дисковых ресурсов и времени.

Выясним текущее состояние вашей базы данных. Для этого выполним простой диагностический SQL-запрос к СУБД:

SELECT count(*) FROM [ИмяВашейБазы].[dbo].[DepotFiles];

Если результат запроса возвращает число более 1000 (а в запущенных случаях — 15 000 – 20 000 записей), таблицу необходимо срочно очистить. Простая очистка таблицы командой DELETE или TRUNCATE без сопутствующих действий принесет лишь временное облегчение. Через несколько сеансов работы конфигуратор заново забьет таблицу мусорными данными. Разберем по шагам правильный и полный регламент лечения:

1. Завершение сеансов: Попросите всех разработчиков закрыть Конфигураторы и отключиться от базы данных и хранилища.
2. Остановка службы: Остановите службу сервера приложений 1С:Предприятие (через консоль services.msc). Это необходимо, чтобы сервер освободил заблокированные файлы кэша конфигурации.
3. Очистка кэша на сервере: Перейдите в каталог службы сервера 1С (по умолчанию это C:\Program Files\1cv8\srvinfo\reg_1541\) и удалите папки временных файлов конфигураций (содержащие кэш конфигураций баз данных).
4. Очистка кэша у пользователей: На компьютерах разработчиков (или на терминальном сервере, если работа ведется в RDP-сессиях) удалите папки локального кэша 1С по путям:
   • %USERPROFILE%\AppData\Local\1C\1cv8\
   • %USERPROFILE%\AppData\Roaming\1C\1cv8\
   Примечание: Очистить нужно именно папки с длинными буквенно-цифровыми GUID-именами. Ключ запуска платформы /clearcache здесь не поможет, так как он очищает кэш запросов данных, а не метаданных конфигурации.
5. Очистка таблицы в СУБД: Выполните SQL-скрипт для быстрой и полной очистки таблицы DepotFiles:
   Скопировать код

   
   USE [ИмяВашейБазы];
   GO
   TRUNCATE TABLE [dbo].[DepotFiles];
   

6. Запуск и подключение: Запустите службу сервера 1С:Предприятие. Откройте Конфигуратор и заново подключите базу данных к хранилищу конфигурации. Платформа создаст чистый, корректный локальный и серверный кэш, а в таблице DepotFiles восстановится минимальное рабочее количество записей.

Часть 2. Мифы и реальность системных счетчиков: разбор Memory: Pages/sec

Администраторы часто бьют тревогу, когда видят в системном мониторе (Performance Monitor) высокие значения счетчика Memory: Pages/sec (например, около 90–100 операций в секунду), при этом сервер располагает десятками гигабайт свободной оперативной памяти. Согласно старым методическим рекомендациям ИТС, превышение порога в 20 страниц в секунду сигнализирует о жесткой нехватке ОЗУ и необходимости её увеличения. Давайте разберемся, почему в современных реалиях это не так.

Счетчик Memory: Pages/sec фиксирует общую сумму двух событий:

• Hard Page Faults (жесткие сбои страниц): Ситуация, когда запрашиваемых данных физически нет в оперативной памяти, и операционная система вынуждена обращаться к файлу подкачки pagefile.sys на диске. Это действительно замедляет систему.
• Soft Page Faults / Memory-Mapped Files: Ситуация, когда приложение обращается к файлу, спроецированному в память (Memory-Mapped File). Это стандартный и очень быстрый механизм работы Microsoft SQL Server с файлами баз данных и логов, а также сервера 1С с кэшем метаданных. ОС подгружает данные из системного дискового кэша, при этом физического обращения к файлу подкачки не происходит.

Для корректной диагностики дефицита оперативной памяти необходимо анализировать другие показатели:

1. Memory: Pages Input/sec: Показывает реальное количество страниц, считываемых с диска для разрешения конфликтов страниц. Если этот показатель близок к нулю — жестких дисковых задержек из-за нехватки ОЗУ нет.
2. Paging File: % Usage: Процент использования файла подкачки. Если этот параметр стабильно держится на уровне менее 5–10%, вашей операционной системе полностью хватает физической оперативной памяти, а высокий показатель Pages/sec является лишь следствием интенсивной работы СУБД с проецируемыми файлами.

Часть 3. Почему двухпроцессорный Xeon работает медленнее ПК на Windows 7

Рассмотрим аппаратные особенности серверных платформ. Ситуация, когда сервер на базе процессоров Intel Xeon (например, семейств E5-2600) уступает в отзывчивости скромному ПК с Windows 7, обусловлена тремя ключевыми факторами: архитектурой процессоров, настройками энергосбережения и организацией дисковой подсистемы.

1. Однопоточная производительность (Single-Core Performance). Многие критические операции в 1С (проведение документов, расчет себестоимости, компиляция модулей в конфигураторе) выполняются строго в один поток. Процессоры Xeon ориентированы на параллельные вычисления: они имеют много ядер, но невысокую тактовую частоту каждого отдельного ядра (например, 2.6 ГГц). Десктопные процессоры (Core i5/i7) имеют гораздо более высокую тактовую частоту ядра (3.5–4.5 ГГц) и более современную архитектуру IPC (инструкций за такт). В результате однопоточная задача на «слабом» ПК завершается быстрее, чем на мощном сервере.

2. Настройки энергосбережения (Power Management). По умолчанию серверные операционные системы семейства Windows Server устанавливают сбалансированную схему электропитания (Balanced Power Plan). В BIOS сервера также по умолчанию активированы технологии энергосбережения (C-States, Intel SpeedStep). Сервер пытается экономить электричество и снижает частоту процессоров до минимума (например, до 1.2 ГГц). При поступлении кратковременной однопоточной задачи от 1С процессор просто не успевает переключиться в режим высокой производительности (Turbo Boost) и выполняет задачу на минимальной частоте.
Решение: В настройках электропитания Windows Server обязательно выберите схему «Высокая производительность» (High Performance), а в BIOS сервера переведите режим энергосбережения в положение "Maximum Performance" (или "Custom" с отключением C-States).

3. Проблемы кэширования RAID-контроллера. В серверах HP Smart Array (например, P420i) производительность дисковой подсистемы критически зависит от работы модуля кэша записи FBWC (Flash-Backed Write Cache). Если встроенный конденсатор (батарея) этого модуля неисправен, разряжен или находится в процессе калибровки, контроллер в целях безопасности мгновенно отключает кэш записи и переходит в режим прямой записи на диски (Write-Through). Без кэша записи скорость работы СУБД падает в 10–50 раз. Это напрямую влияет на скорость работы tempdb и транзакционных логов.
Решение: Откройте утилиту HP Smart Storage Administrator (SSA) и проверьте состояние батареи конденсатора. При необходимости замените её или временно включите принудительное кэширование записи без батареи (Force Write Back with No Battery), если сервер подключен к надежному источнику бесперебойного питания (ИБП).

4. Плотное совмещение ролей (SQL + 1С + RDP). Размещение СУБД MS SQL Server, сервера приложений 1С и терминального сервера (RDP) для 20+ пользователей на одной физической машине — классическая архитектурная ошибка. Пользователи терминалов запускают тяжелые веб-браузеры, офисные пакеты и другие приложения, которые вызывают постоянное переключение контекста процессора и搶 (захватывают) ресурсы оперативной памяти. СУБД MS SQL крайне чувствительна к приоритету потоков и скорости работы дисковой подсистемы. В условиях конкуренции за ресурсы с терминальными сессиями общая производительность 1С падает по экспоненте. Рекомендуется разделять эти роли по разным виртуальным или физическим машинам.