При совместном размещении сервера 1С:Предприятия и СУБД Microsoft SQL Server на одной физической машине дисковая подсистема становится критически важным узлом. Когда пользователи начинают жаловаться на замедление работы системы, в диспетчере задач нередко обнаруживаются системные процессы, создающие пиковую нагрузку на чтение и запись. Разберем по шагам, почему процесс wbengine перегружает диски, как правильно управлять архивацией Windows и как выяснить, какая база данных нагружает SQL Server при отсутствии активных пользователей.
Процесс wbengine.exe представляет собой службу подсистемы архивации Windows Server (Windows Server Backup Engine). Данная служба активируется планировщиком задач Windows или вручную для создания теневых копий томов (VSS) и создания полных резервных копий состояния системы и дисков. При создании бэкапа дисковые накопители подвергаются интенсивным операциям блочного чтения и записи, что приводит к возникновению очередей к диску и зависанию сеансов 1С.
Проанализируем порядок действий для устранения конфликта с wbengine:
wbadmin.msc) и проверим текущее расписание создания резервных копий. Выясним, перекрывает ли график архивации рабочие часы пользователей 1С.services.msc), найдем службу «Служба архивации данных Windows Server» (Block Level Backup Engine Service), изменим тип запуска на Вручную или Отключена и остановим выполняющийся процесс.Часто возникает ситуация, когда после завершения процесса архивации служба sqlservr.exe продолжает интенсивно нагружать дисковую подсистему операциями чтения и записи, даже если все пользователи отключились от баз 1С. Выясним причину и локализуем источник нагрузки средствами SQL Server Management Studio (SSMS).
Разберем способы поиска базы и конкретных операций:
ALTER INDEX REBUILD), обновление статистики, проверка целостности (DBCC CHECKDB) или резервное копирование баз данных.sys.dm_io_virtual_file_stats, чтобы увидеть суммарную статистику дисковых операций в разрезе каждого файла данных (.mdf) и журнала транзакций (.ldf):
SELECT
DB_NAME(vfs.database_id) AS DatabaseName,
mf.name AS LogicalFileName,
mf.type_desc AS FileType,
vfs.num_of_reads,
vfs.num_of_bytes_read,
vfs.num_of_writes,
vfs.num_of_bytes_written,
vfs.io_stall_read_ms,
vfs.io_stall_write_ms
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS vfs
JOIN sys.master_files AS mf
ON vfs.database_id = mf.database_id AND vfs.file_id = mf.file_id
ORDER BY (vfs.num_of_bytes_read + vfs.num_of_bytes_written) DESC;
sys.dm_exec_requests и sys.dm_exec_sql_text:
SELECT
r.session_id,
DB_NAME(r.database_id) AS DatabaseName,
r.status,
r.command,
r.cpu_time,
r.total_elapsed_time,
r.reads,
r.writes,
r.logical_reads,
t.text AS ExecutingSQL
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t
WHERE r.session_id != @@SPID;
Если в СУБД не запущены планы обслуживания, дисковую активность могут вызывать фоновые и регламентные задания самой платформы 1С. Даже при закрытых сеансах пользователей кластер серверов 1С продолжает выполнять запланированные процедуры.
Проверим следующие ключевые задачи:
ОбновлениеИндексаППД и СлияниеИндексовППД при большом объеме измененных данных создают существенную нагрузку на диск.Для управления этими процессами откроем базу в режиме 1С:Предприятие и воспользуемся типовой обработкой Консоль регламентных заданий или формой администрирования регламентных заданий в разделе администрирования. При необходимости скорректируем расписание их запуска, чтобы разнести тяжелые задачи по времени.
Рассмотрим технические настройки, позволяющие избежать дисковых задержек:
rphost, rmngr) в файл подкачки Windows, что резко увеличивает дисковый I/O. Настроим параметр Max Server Memory в свойствах сервера SQL так, чтобы оставить достаточный объем памяти (от 4 до 8 Гб и более) для ОС и процессов 1С.Perform volume maintenance tasks). Это избавит систему от необходимости занулять выделяемое дисковое пространство при росте файлов .mdf..mdf), журналы транзакций (.ldf) и системную базу tempdb на раздельных физических накопителях или RAID-массивах.