← На главную

При росте информационной базы 1С:Предприятия 7.7 системные администраторы и разработчики часто сталкиваются с существенным замедлением операций, особенно при массовом перепроведении документов или восстановлении последовательностей. Закономерно возникает мысль модернизировать инфраструктуру: перейти с устаревшего MS SQL Server 2000 на MS SQL Server 2005 или 2008, добавить оперативной памяти и перенести систему на современное серверное многоядерное "железо". Однако на практике такой переход нередко приводит к обратному эффекту: скорость проведения документов не только не растет, но и заметно снижается. Разберем по шагам, почему это происходит, какие узкие места существуют у платформы 7.7 и как правильно настроить окружение для максимальной производительности.

Архитектурные ограничения платформы 1С 7.7 и аппаратные факторы

Проанализируем технические причины, по которым новое серверное оборудование может работать медленнее старой рабочей станции:

1. Производительность на одно ядро (Single-Core IPC): Платформа 1С 7.7 представляет собой 32-битное приложение с однопоточной архитектурой клиентского сеанса. При групповом проведении документов вся бизнес-логика выполняется последовательно и нагружает ровно одно процессорное ядро. Установка многопроцессорных серверных платформ со старыми многоядерными чипами (например, серий с невысокой базовой тактовой частотой) приводит к падению производительности на ядро по сравнению с десктопными процессорами того же поколения. Для 1С 7.7 решающее значение имеет максимальная тактовая частота и высокая производительность одного ядра, а не общее количество ядер на сервере.
2. Дисковая подсистема и очереди ввода-вывода: При проведении документов СУБД выполняет колоссальный объем операций случайной записи, активно взаимодействуя с журналом транзакций базы (файл .ldf) и системной базой данных tempdb. Массивы из обычных накопителей SATA (даже собранные в RAID 10) имеют высокую задержку отклика по сравнению с высокоскоростными SAS-дисками со скоростью вращения 10k/15k или твердотельными накопителями с аппаратным контроллером и энергонезависимым кэшем записи.
3. Буферный пул и оперативная память: Переход на 64-битную операционную систему и 64-битный SQL Server снимает ограничение в 2 Гб адресного пространства для самого SQL-сервера, позволяя ему кэшировать базу целиком в ОЗУ. Однако сама операция массового проведения упирается не столько в чтение данных из кэша, сколько в фиксацию транзакций на диске и последовательную генерацию запросов на клиенте.

Особенности взаимодействия 1С 7.7 с MS SQL Server 2005/2008

Штатно платформа 1С 7.7 разрабатывалась под MS SQL Server 6.5, 7.0 и 2000. При работе с более новыми версиями СУБД (2005, 2008 и новее) через режим совместимости меняется поведение оптимизатора запросов и механизма блокировок:

1. Работа с курсорами (sp_cursorfetch): Движок 1С 7.7 интенсивно использует платформенные API-серверные курсоры при обходе выборок и позиционировании. В MS SQL Server 2005 и 2008 обработка курсоров претерпела изменения, что при неоптимальных индексах вызывает дополнительные накладные расходы при выборках, например, по таблице подчиненных документов _1SCRDOC.
2. Деградация скорости при непрерывном проведении: Замедляющийся темп обработки каждого последующего документа вызван утечкой ресурсов внутри клиентской библиотеки bkend.dll. В длительном цикле накапливаются дескрипторы метаданных и внутренних объектов, которые не очищаются вплоть до полного перезапуска процесса сеанса 1cv7s.exe.
3. Журнал транзакций и контрольные точки: Постоянные изменения в таблице журнала документов _1SJOURN и проводках создают непрерывный поток данных в журнал транзакций. Без периодической фиксации или при автоматическом росте файлов СУБД тратит ресурсы на выделение места и сброс страниц на диск (Checkpoints).
4. Автоматический пересчет статистики: При интенсивной вставке строк срабатывает автоматическое обновление статистики СУБД. Это приводит к временным блокировкам планов выполнения и замиранию процесса проведения.

Тонкая настройка MS SQL Server для работы с 1С 7.7

Если эксплуатация базы данных ведется на MS SQL Server 2005 или 2008, выполним комплекс обязательных сервисных настроек:

1. Язык учетной записи пользователя СУБД: В свойствах пользователя (Login) в SQL Server Management Studio обязательно укажем язык по умолчанию (Default Language) — English. Если оставить русский язык, во встроенных хранимых процедурах пересчета регистров (вида _1sp_*) возникают неявные ошибки преобразования формата дат, что приводит к переходу на сканирование таблиц целиком (Table Scan) и тяжелым взаимоблокировкам.
2. Отключение контроля сортировки: Для предотвращения системных ошибок порядка кодовой страницы поместим пустой текстовый файл с именем OrdNoChk.prm в каталог BIN установленной платформы 1С:Предприятия.
3. Флаги трассировки СУБД:

   В параметры запуска службы SQL Server добавим флаг -T1118. Данный параметр принудительно отключает выделение смешанных экстентов (Mixed Extents), устраняя конфликты распределения страниц на служебных страницах SGAM и GAM в tempdb, что критически важно при множественных клиентских курсорах.

   Для SQL Server 2008 и 2008 R2 рекомендуется также использовать флаг трассировки -T4199, включающий накопленные исправления оптимизатора запросов.

4. Конфигурация tempdb и файлов базы данных:

   Создадим несколько файлов данных для базы tempdb с абсолютно одинаковым начальным размером и шагом автороста (количество файлов рекомендуется выбирать по числу физических ядер, но не более 8).

   Зададим фиксированный шаг автоматического увеличения файлов данных (.mdf) и лога транзакций (.ldf) в мегабайтах (например, по 200–500 Мб), исключив прирост в процентах. Это защитит сервер от фрагментации и задержек при динамическом увеличении файлов.

   Обязательно отключим параметры AUTO_CLOSE и AUTO_SHRINK в свойствах рабочей базы данных.

5. Закрепление страниц в оперативной памяти (Lock Pages in Memory): В 64-битных ОС назначим учетной записи, от имени которой запущена служба SQL Server, локальную привилегию Lock Pages in Memory через оснастку локальных политик безопасности Windows (secpol.msc). Это предотвратит выгрузку страниц буферного пула СУБД в файл подкачки при дефиците памяти.

Практические методы решения проблемы медленного проведения

Рассмотрим способы, позволяющие принципиально решить проблему падения скорости без полной переработки учетной системы:

1. Пакетное дробление и перезапуск сеанса: Поскольку основная утечка памяти и ресурсов происходит в контексте клиентского приложения 1С, разобьем задачу перепроведения документов на короткие интервалы (например, по несколько дней или по неделям). Между пачками организуем перезапуск сеанса 1С через командную строку или командные пакетные файлы, полностью очищая адресное пространство процесса.
2. Управление точкой актуальности (ТА): При проведении документов "задним числом" платформа 1С 7.7 автоматически пересчитывает все последующие итоги регистров вплоть до текущей точки актуальности. Если необходимо перепровести массив документов за прошлый период, целесообразно предварительно временно сместить точку актуальности на дату конца перепроводимого периода, выполнить расчет и затем вернуть ее на текущий момент. Это многократно сократит объем обновляемых записей в таблицах итогов.
3. Использование прямых запросов: Для аналитических выборок, отчетов и массовых корректировок данных откажемся от стандартных тяжелых объектных методов обхода документов. Использование внешних компонент (таких как проект 1С++) позволяет выполнять прямые SQL-запросы к таблицам базы минуя медленные механизмы sp_cursorfetch, обеспечивая максимальное быстродействие на современных версиях SQL Server.