← На главную

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

Что выбирает запрос к таблице _1SJOURN

Рассмотрим синтаксис и механику выполнения следующего запроса к базе данных 1С 7.7:

SELECT * FROM _1SJOURN WHERE DOCNO LIKE '%1%'

Проанализируем структуру этого запроса и логику его обработки сервером СУБД:

1. Таблица _1SJOURN — это системная таблица общего журнала документов в 1С 7.7. В ней хранятся заголовки абсолютно всех созданных в информационной базе документов (дата, время, номер, вид документа, флаги проведения и т.д.). В активно работающих системах эта таблица насчитывает сотни тысяч и миллионы строк, являясь одной из самых объемных.
2. Поле DOCNO содержит номер документа в виде строкового значения.
3. Условие LIKE '%1%' с символом маски в начале шаблона делает невозможным использование стандартного b-tree индекса по полю DOCNO. Оптимизатор СУБД не может выполнить точечный поиск по дереву индекса (Index Seek).
4. В результате СУБД вынуждена применить полное сканирование таблицы (Table Scan или Clustered Index Scan), последовательно считывая все страницы данных с диска или из буферного кэша оперативной памяти для проверки каждой строки на наличие символа «1».

Такой запрос часто используют в качестве грубого синтетического теста: он создает тяжелую дисковую нагрузку на чтение, нагружает процессор поиском подстроки и проверяет пропускную способность подсистемы памяти.

Почему мощный сервер выигрывает в синтетическом тесте, но проигрывает в реальной 1С 7.7

Выясним причину парадокса, когда современный сервер выполняет SELECT за 16 секунд против 41 секунды на старом ПК, но при проведении документов работает медленнее.

1. Однопоточная архитектура клиентской части 1С 7.7

Вся прикладная логика модулей проведения документов, контроля остатков и восстановления последовательностей в 1С 7.7 исполняется строго синхронно в одном потоке. Платформа не умеет распределять проведение одного документа на несколько ядер процессора. Решающее значение здесь имеет производительность на одно ядро (IPC и тактовая частота). Процессор с высокой тактовой частотой на ядро в однопоточном сценарии 1С 7.7 будет быстрее многоядерного сервера с более низкой базовой частотой ядер.

2. Специфика формирования запросов и транзакций

В отличие от тяжелого параллельного запроса SELECT, платформа 1С 7.7 при проведении документов генерирует огромное количество мелких точечных запросов и транзакций через серверные курсоры (построчная обработка данных). В этом режиме узким местом становится не линейная скорость чтения данных, а время отклика и задержка при синхронной фиксации каждой транзакции в журнале (.ldf).

3. Различия в оптимизаторах MS SQL 2000 и MS SQL 2008

Платформа 1С 7.7 разрабатывалась под особенности MS SQL 2000. В более свежих версиях СУБД (MS SQL 2005/2008 и выше) оптимизатор пытается распараллеливать даже небольшие подзапросы 1С, что на многопроцессорных системах приводит к накладным расходам на межпоточную синхронизацию (ожидания типа CXPACKET) и вызывает деградацию общей скорости транзакций.

Шаги по настройке и оптимизации MS SQL для 1С 7.7

Разберем по шагам параметры, которые необходимо настроить на сервере СУБД для обеспечения максимального быстродействия 1С 7.7:

1. Ограничение параллелизма (MAXDOP): в свойствах сервера SQL Server (раздел Advanced) установите параметр Max Degree of Parallelism = 1. Это отключит параллельное выполнение простых запросов 1С и исключит задержки на синхронизацию потоков.
2. Уровень совместимости базы данных (Compatibility Level): для базы 1С 7.7 на MS SQL 2008 рекомендуется установить уровень совместимости SQL Server 2000 (80) в свойствах базы данных.
3. Размещение журнала транзакций (.ldf): при проведении документов СУБД непрерывно сбрасывает транзакции на диск. Файл .ldf должен располагаться на дисковом массиве с минимальной задержкой произвольной записи (на быстром SSD или SAS-массиве с аппаратным RAID-контроллером, работающим в режиме Write-Back с исправным модулем защиты кэша BBU).
4. Асинхронное обновление статистики: включите параметр базы данных Auto Update Statistics Asynchronously (в свойствах базы данных, раздел Options), чтобы исключить внезапные блокировки пользовательских сеансов при автоматическом обновлении статистики по таблицам _1SJOURN и регистрам.
5. Использование прямых запросов: для критически важных тяжелых отчетов и алгоритмов регламентной обработки в 1С 7.7 рекомендуется использовать внешние компоненты прямого доступа к СУБД, что позволяет перенести вычисления на сторону MS SQL Server вместо построчной выгрузки таблиц на клиентский компьютер.