Перевод базы данных 1С:Предприятия 7.7 на твердотельные накопители (SSD) — частая мера, к которой прибегают системные администраторы в надежде кардинально ускорить восстановление последовательности документов, проведение реализаций или расчет итогов. Однако на практике прирост производительности нередко составляет считанные проценты: например, длительная операция вместо 2 часов 20 минут выполняется за 2 часа 10 минут. Одновременно с этим процесс СУБД загружает восьмиядерный процессор ровно на 12.5–13%, то есть задействует только одно физическое ядро. Выясним причины такого поведения системы, разберем архитектурные ограничения платформы 7.7 и рассмотрим практические шаги по оптимизации конфигурации сервера.
Разберем, почему установка SSD в ряде задач не дает заметного эффекта. Дисковая подсистема является узким местом только тогда, когда диски непрерывно загружены на 100%, а длина очереди к диску превышает допустимые значения. Если массив из нескольких жестких дисков (например, RAID 10) и оперативная память сервера уже справляются с дисковыми операциями благодаря кэшированию страниц данных в буферном пуле MS SQL Server, замена носителей на SSD сама по себе не может ускорить обработку логики.
Кроме того, характер нагрузки 1С 7.7 специфичен:
tempdb часто не вырастает больше пары десятков мегабайт, поскольку однопоточные запросы платформы практически не задействуют сложные планы с тяжелыми сортировками на диске.Многие администраторы задаются вопросом: почему при наличии 8 или 16 ядер сервер загружен суммарно всего на 12–13%? Рассмотрим математику распределения вычислительных ресурсов: при наличии 8 ядер полная загрузка ровно одного ядра процессом sqlservr.exe отображается в диспетчере задач как 100 / 8 = 12.5%.
Это происходит по двум причинам:
SELECT, следующий запрос не отправляется.cost threshold for parallelism равен 5), запрос никогда не распараллеливается между несколькими потоками. Так как подавляющее большинство запросов 1С 7.7 крайне просты, они физически не могут быть разделены на несколько ядер и выполняются в один поток.Попытки форсировать многопоточность для таких запросов не только не ускоряют систему, но и приводят к деградации: оптимизатор тратит драгоценное процессорное время на оценку возможности параллелизма и синхронизацию потоков.
Для платформы 1С 7.7 крайне важно отключить распараллеливание запросов на уровне экземпляра MS SQL Server, принудительно задав значение параметра max degree of parallelism (MAXDOP), равное 1. Рассмотрим, как это сделать через SQL Server Management Studio:
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
GO
EXEC sp_configure 'max degree of parallelism', 1;
RECONFIGURE;
GO
Установка этого параметра в единицу гарантирует, что оптимизатор запросов не будет предпринимать попыток разделить элементарные запросы платформы на параллельные подзадачи, снижая накладные расходы процессора на синхронизацию потоков.
Проанализируем сетевую составляющую. Работа пользователей с базой 1С 7.7 через сетевую папку (SMB-шару) по схеме «толстого клиента» порождает критическое узкое место: задержку передачи пакетов (Round-Trip Time, RTT). Миллионы мелких обращений идут по цепочке: «клиент сформировал запрос — передал по сети — SQL Server выполнил — ответ ушел по сети — клиент получил и сформировал следующий запрос».
Если задержка в сети между клиентом и сервером составляет хотя бы 0.3–0.5 мс, физическая среда передачи съедает большую часть суммарного времени выполнения операции. Именно поэтому локальное выполнение на сервере всегда происходит в разы быстрее, чем запуск по локальной сети, даже если кабельная сеть работает на скорости 1 Гбит/с.
Для кардинального ускорения работы необходимо выполнить следующие шаги:
Shared Memory (общая память), полностью исключая физические сетевые задержки сетевой карты и коммутаторов.1Cv7.mlg, а также контролировать размер пользовательских файлов 1cv7.cfg. Разрастание этих файлов свыше нескольких мегабайт вызывает зависания при старте и завершении транзакций в файловой части базы.Разберем параметры СУБД и операционной системы, которые позволяют выжать максимум производительности из однопоточных операций:
ALTER DATABASE [ИмяБазы1С] SET COMPATIBILITY_LEVEL = 80;
GO
-T1118 отключает использование смешанных экстентов (mixed extents), сразу выделяя однородные экстенты по 64 КБ, что предотвращает блокировки служебных страниц PFS/SGAM в tempdb и основной базе. Флаг -T2371 делает пересчет автостатистики динамическим, что критично для больших таблиц движений регистров.SE_MANAGE_VOLUME_NAME («Выполнение задач по обслуживанию томов»). Это предотвратит обнуление дискового пространства нулями при авторасширении файлов данных .mdf, снижая дисковые задержки при интенсивной записи.AUTO_SHRINK и AUTO_CLOSE отключены, чтобы не создавать искусственную фрагментацию дисков и постоянную переинициализацию контекста.Чтобы прекратить гадание и объективно выявить причину медленной работы, необходимо использовать штатный инструмент «Системный монитор» (Performance Monitor), а не базовый «Диспетчер задач» или «Монитор ресурсов».
Рассмотрим порядок правильного сбора метрик:
PhysicalDisk(*)\Current Disk Queue Length (текущая длина очереди к диску — показатель перегрузки дисковой подсистемы);PhysicalDisk(*)\Avg. Disk sec/Read и Avg. Disk sec/Write (задержка чтения/записи в секундах; норма для SSD — менее 0.005 с);Processor(*)\% Processor Time (загрузка ядер по отдельности, а не суммарная по процессору);Network Interface(*)\Bytes Total/sec и Output Queue Length (нагрузка на сетевые адаптеры).Таким образом, для платформы 1С 7.7 решающее значение имеют не столько дисковые накопители, сколько тактовая частота одного процессорного ядра (лучше меньше ядер, но с более высокой базовой частотой без энергосбережения), устранение сетевых задержек путем переноса сеансов на терминальный сервер и ограничение параллелизма СУБД.