Каждый разработчик и системный администратор 1С рано или поздно сталкивается с ситуацией, когда локальная база начинает невыносимо тормозить. При этом, открыв Диспетчер задач Windows, мы видим пугающую картину: активное время диска стабильно держится на отметке 100%, хотя скорость чтения или записи колеблется на смешных значениях в 1–10 МБ/с. В то же время обычное копирование файлов на этот же диск легко выдает 100–150 МБ/с. В этой статье мы подробно разберем физику этого процесса, выясним, почему так происходит, и пошагово настроим систему для решения этой проблемы.
Для начала проанализируем, что именно означает параметр «Активное время» (Active Time) в операционной системе Windows. Этот показатель отражает процент времени, в течение которого дисковый накопитель был занят выполнением запросов на чтение или запись. Он не имеет прямого отношения к пропускной способности (мегабайтам в секунду), а напрямую связан с количеством запросов и временем их обработки.
Рассмотрим разницу между двумя типами нагрузок на жесткий диск (HDD):
В результате жесткий диск упирается в свой технологический лимит — показатель IOPS (Input/Output Operations Per Second). Для дисков класса 5900 RPM предел составляет всего около 75–90 IOPS. Как только СУБД отправляет к накопителю более 100 запросов в секунду, диск физически не успевает перемещать головку. Скорость передачи данных падает до жалких 1–5 МБ/с, очередь запросов растет, а активное время диска намертво зависает на 100%. Диск работает на пределе своих физических возможностей, выполняя колоссальную механическую работу, но полезный выхлоп при этом минимален.
Прежде чем переходить к глубоким настройкам СУБД, снизим паразитную дисковую нагрузку со стороны самой Windows. По умолчанию в ОС работает несколько служб, которые буквально парализуют медленные HDD постоянным сканированием файлов.
Рассмотрим, какие службы необходимо отключить в первую очередь:
services.msc (Службы), найдите Windows Search, остановите ее и выберите тип запуска «Отключена».*.mdf, *.ldf, *.1CD). Постоянная проверка изменяющихся файлов баз данных «на лету» способна затормозить даже производительную дисковую подсистему.Если ваша тестовая база развернута на MS SQL Server, мы можем применить несколько профессиональных трюков, которые кардинально снизят нагрузку на дисковые головки HDD.
По умолчанию при создании, восстановлении или автоматическом расширении файлов баз данных (MDF) SQL Server заполняет новое дисковое пространство нулями. На медленном HDD процесс расширения файла базы на пару гигабайт приводит к глухому зависанию 1С и 100% нагрузке на диск.
Выясним, как это исправить. Нам необходимо предоставить учетной записи, от имени которой запущена служба SQL Server, специальную привилегию в операционной системе — «Выполнение задач по обслуживанию томов» (Perform volume maintenance tasks). Разберем шаги:
secpol.msc (Локальная политика безопасности) и нажмите Enter.NT Service\MSSQLSERVER).Теперь SQL Server будет мгновенно резервировать место на диске под файлы данных без физической перезаписи секторов нулями.
По умолчанию для баз данных может быть установлено авторасширение в процентах (например, на 10%). При достижении лимита база заблокирует работу пользователей и начнет медленно увеличивать файл. Для HDD это критично.
Рекомендуем настроить фиксированный шаг расширения в мегабайтах. Для этого в SQL Server Management Studio (SSMS) откройте свойства вашей базы данных, перейдите на вкладку «Файлы» (Files) и настройте авторасширение:
Системная база данных tempdb используется 1С непрерывно для построения временных таблиц при сложных запросах и расчетах отчетов. Это один из самых нагруженных компонентов. Поскольку мы работаем на локальном компьютере разработчика, мы можем полностью исключить обращение к HDD для базы tempdb, перенеся ее в оперативную память.
Для этого мы можем использовать бесплатное программное обеспечение для создания RAM-дисков (например, ImDisk). Создайте виртуальный диск в оперативной памяти размером 1–2 ГБ и перенаправьте туда файлы tempdb с помощью следующего скрипта в SSMS:
USE master;
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = 'R:\TempDB\tempdb.mdf');
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = templog, FILENAME = 'R:\TempDB\templog.ldf');
GO
Обратите внимание: буква диска 'R' в примере должна соответствовать букве вашего RAM-диска. После выполнения скрипта необходимо перезапустить службу SQL Server.
Важно понимать, что лучшим «ускорителем» диска является достаточный объем оперативной памяти. СУБД старается кэшировать прочитанные таблицы в ОЗУ (Buffer Pool). Если памяти серверу выделено мало (например, всего 4 ГБ при размере активной базы в 10–15 ГБ), то SQL Server будет постоянно вытеснять старые страницы из памяти, чтобы прочитать новые с медленного диска. Этот процесс называется «вымыванием кэша».
Проанализируем показатель Page Life Expectancy (PLE) — ожидаемое время жизни страницы в секундах. Мы можем запустить следующий SQL-запрос для мониторинга этого показателя:
SELECT [object_name], [counter_name], [cntr_value]
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE '%Buffer Manager%'
AND [counter_name] = 'Page life expectancy';
Если полученное значение регулярно падает ниже 300 секунд — это явный сигнал того, что SQL Server задыхается без памяти и постоянно насилует жесткий диск повторным чтением данных. Выделите под SQL Server как можно больше оперативной памяти, оставив операционной системе необходимый минимум (около 3 ГБ).
Неэффективные запросы в 1С могут заставить СУБД считывать терабайты данных с диска. Если статистика базы данных устарела, оптимизатор SQL Server строит некорректный план запроса. Вместо быстрого поиска по индексу (Index Seek) сервер выполняет полное сканирование всей таблицы (Clustered Index Scan), перемалывая миллионы записей на медленном HDD.
Регулярно выполняйте обслуживание базы данных. Запустите в SSMS следующие команды для обновления статистики и дефрагментации индексов:
-- Обновление статистики для всей базы данных
EXEC sp_updatestats;
GO
Также в настройках базы данных рекомендуется перевести модель восстановления (Recovery Model) в режим Simple (Простая). Это предотвратит бесконтрольный рост журнала транзакций (файла LDF) и снизит общую дисковую нагрузку на запись логов.
Мы рассмотрели множество программных способов оптимизации и снижения дисковой активности. Они способны облегчить жизнь медленному жесткому диску, но полностью решить проблему производительности 1С на HDD физически невозможно. Современная платформа 1С v8.3 архитектурно спроектирована под высокие показатели IOPS.
Для комфортной работы разработчика или бухгалтера использование SSD-накопителя в 2024 году является не роскошью, а минимальным системным требованием. Твердотельные накопители (SSD) обеспечивают от 50 000 до 500 000 IOPS на случайном чтении мелких блоков, что в тысячи раз превосходит возможности любого, даже самого надежного серверного HDD (такого как Seagate IronWolf). Перенос базы данных 1С и файлов СУБД на SSD мгновенно снизит активное время диска до комфортных единиц процентов и уберет все зависания интерфейса программы.