Ситуация, когда информационная база 1С достигает объема в 2,5 терабайта при одновременной работе более 1000 пользователей, является экстремальной для архитектуры «Управление торговлей 10.3». На таких масштабах стандартные методы оптимизации перестают давать видимый эффект, и требуется комплексный подход, затрагивающий серверное железо, настройки СУБД, параметры кластера 1С и саму структуру данных. Рассмотрим подробно, как диагностировать и устранить причины деградации производительности в подобных системах.
Разберем первопричину проблем. Конфигурация УТ 10.3 базируется на «обычных формах» и, как правило, использует автоматический режим блокировок в свойствах метаданных. При 1000 пользователей это становится критическим узким местом. В автоматическом режиме MSSQL блокирует целые таблицы или большие диапазоны страниц при записи, что заставляет остальных пользователей ждать завершения транзакции даже при попытке простого чтения данных.
Проанализируем шаги по изменению стратегии блокировок:
При объеме базы 2,5 Тб стандартных настроек СУБД недостаточно. Выясним, какие параметры требуют тонкой настройки:
Настройка TempDB: Поскольку 1С активно использует временные таблицы, TempDB становится «раскаленной» точкой. Проверим, чтобы файлы TempDB были вынесены на самый быстрый NVMe-накопитель, отдельный от файлов основной базы .mdf и лога транзакций .ldf. Количество файлов данных TempDB должно соответствовать количеству логических ядер процессора (но обычно не более 8-16 для предотвращения фрагментации).
Параметры параллелизма: Проанализируем настройки MAXDOP (Maximum Degree of Parallelism). Для 1С классической рекомендацией является значение 1. Однако на базах свыше 1 Тб для выполнения тяжелых регламентных операций чтения можно протестировать значения 2 или 4. При этом крайне важно поднять Cost Threshold for Parallelism до 50, чтобы SQL-сервер не пытался распараллеливать каждый мелкий запрос, что порождает накладные расходы на управление потоками.
Обслуживание индексов и статистики: В огромной базе фрагментация индексов происходит стремительно. Посмотрим на критические регламенты:
Fill Factor (коэффициент заполнения) для индексов активно пишущихся таблиц на уровне 80-85%. Это уменьшит количество операций расщепления страниц (Page Splits) и снизит нагрузку на дисковую подсистему при интенсивной записи.Часто причиной «лагов» при открытии форм является сетевое «горлышко». В конфигурации с выделенным сервером БД и сервером приложений стандартный канал 1 Гбит/с является недостаточным для 1000 пользователей. При открытии формы списка справочника Номенклатура или Продажи система передает значительные объемы данных между серверами. Обязательно используйте канал 10 Гбит/с между сервером 1С и SQL-сервером.
Разберем настройку рабочих процессов кластера 1С:
Для 1000 пользователей одного или двух процессов rphost недостаточно. Рекомендуется создавать рабочие процессы из расчета 1 процесс на 25-30 пользователей. Это позволит распределить нагрузку на память и избежать ситуации, когда критическая ошибка в сессии одного пользователя приводит к «падению» или зависанию процесса для остальных 500 человек.
Настроим автоматический перезапуск процессов:
// Параметры в консоли администрирования кластера:
Допустимый объем памяти: 4 000 000 КБ (индивидуально)
Интервал превышения допустимого объема памяти: 300 сек.
Выключать процессы через: 1000 сек.
В УТ 10.3 механизм RLS (ограничение доступа на уровне записей) реализован через добавление условий в каждый SQL-запрос. На базе 2,5 Тб это приводит к тому, что простые запросы превращаются в монструозные конструкции с множеством JOIN.
Выясним, как облегчить работу системы:
Если после всех технических настроек производительность остается неудовлетворительной, необходимо признать: архитектура УТ 10.3 исчерпала свой ресурс масштабируемости. Рассмотрим, почему свертка является наиболее действенным методом в данном случае.
Физический размер таблиц напрямую влияет на глубину B-дерева индексов. В базе объемом 2,5 Тб поиск по индексу требует большего количества операций ввода-вывода, чем в базе объемом 200 Гб. Свертка (обрезание истории и перенос остатков на начало года) позволяет:
Проанализируем альтернативу свертке: переход на «1С:Управление торговлей 11». Новая архитектура на управляемых формах и механизм «интеркампани», а также оптимизированные регистры изначально проектировались под высокие нагрузки и большие объемы данных. Однако, если переход невозможен в краткосрочной перспективе, перенос остатков в чистую базу УТ 10.3 — это единственный гарантированный способ вернуть системе былую скорость работы.
Подведем итог наших действий. В первую очередь проверяем сетевой интерфейс (переходим на 10Gb) и включаем RCSI на SQL-сервере. Далее настраиваем TempDB и MAXDOP. Если задержки сохраняются при открытии форм — оптимизируем RLS и накладываем жесткие фильтры на периоды в списках. Если и это не помогает — планируем свертку базы до объема, не превышающего 300-500 Гб, что обеспечит комфортную работу еще на несколько лет.