Ситуация, когда серверная инфраструктура кажется избыточной, но при достижении определенного порога подключений (например, 40 сеансов) производительность падает в 5-10 раз, является классической проблемой «бутылочного горлышка». Разберем подробно, почему это происходит и как выявить истинную причину: от настроек «железа» до логических ошибок в программном коде 1С.
Часто администраторы полагаются на высокую тактовую частоту десктопных процессоров (например, Intel Core i7), забывая о серверных особенностях работы ОС. Проанализируем влияние режима энергосбережения. В Windows Server по умолчанию может быть включен план «Сбалансированный», который динамически меняет частоту ядер. При резком росте нагрузки (заход 40-го пользователя) система не успевает мгновенно «разбудить» ядра, что вызывает микрофризы.
Рассмотрим результаты тестов: переключение в режим «Высокая производительность» в настройках электропитания Windows и отключение состояний C-States в BIOS материнской платы может повысить производительность в тестах (например, тест Гилева) более чем в два раза. Это происходит потому, что процессор перестает тратить время на переходы между энергосберегающими режимами.
Посмотрим на настройки SQL-сервера. Распространенная ошибка — выделение памяти «на глаз». Если база данных имеет размер 150 ГБ, а SQL-серверу выделено всего 16 ГБ из 32 ГБ доступных, система начинает активно использовать файл подкачки и сбрасывать кэш страниц с диска. Проанализируем показатели Buffer Cache Hit Ratio — если этот параметр падает ниже 99%, памяти катастрофически не хватает.
Также важно настроить параллелизм. Для процессоров с малым количеством ядер и высокой частотой (как i7) рекомендуется установить значение Max Degree of Parallelism (MAXDOP) в 1. Это предотвратит ситуацию, когда один тяжелый запрос «размазывается» по всем ядрам, блокируя работу остальных 39 пользователей. Параметр Cost Threshold for Parallelism стоит поднять до 50, чтобы мелкие запросы гарантированно выполнялись на одном ядре.
Выясним неочевидную причину тормозов, связанную с итогами регистров. В 1С существует механизм расчета итогов, который обычно работает помесячно. Если в базу попадает документ с опечаткой в дате (например, 0017 год вместо 2017), платформа пытается рассчитать и хранить итоги за каждые 30 дней на протяжении двух тысяч лет.
Проанализируем ситуацию: это порождает миллионы пустых записей в таблицах итогов (_AccumRegTotals...). При любом движении по такому регистру SQL-сервер вынужден пересчитывать огромный массив данных. Для поиска таких «аномалий» воспользуемся внешней обработкой для проверки минимальных дат в регистрах. Если найдены даты ранее начала ведения учета, их необходимо исправить, а итоги — пересчитать на текущую дату.
Разберем, почему совмещение ролей терминального сервера (RDP), сервера 1С и SQL-сервера на одной машине вредно при 40+ пользователях. Каждая RDP-сессия создает нагрузку на видеоподсистему и планировщик задач ОС. Windows Server начинает применять механизмы Fair Share, пытаясь честно распределить ресурсы между всеми 40 пользователями, что приводит к огромному количеству переключений контекста (Context Switches/sec).
Рассмотрим рекомендации по разделению ролей:
Shared Memory (LPC), который значительно быстрее TCP/IP.Проанализируем ситуацию с помощью Технологического Журнала (ТЖ). Если 30-40 пользователей генерируют около 13 000 запросов в секунду к SQL-серверу — это явный признак неоптимизированного кода. Выясним причину: часто это запросы внутри циклов или в обработчиках ПриВыводеСтроки (для обычных форм) и УсловноеОформление (для управляемых форм), где запрос выполняется для каждой видимой строки списка.
Пример неоптимизированного кода, который «кладет» базу при росте числа пользователей:
// ОШИБКА: Запрос в цикле при выводе строк списка
Для Каждого Строка Из ОформленияСтрок Цикл
Запрос = Новый Запрос("ВЫБРАТЬ Остаток ИЗ Регистр.Остатки ГДЕ Номенклатура = &Ном");
Запрос.УстановитьПараметр("Ном", Строка.ДанныеСтроки.Ссылка);
// Выполнение запроса для каждой строки!
Результат = Запрос.Выполнить().Выгрузить();
КонецЦикла;
Вместо этого следует использовать методику «запроса в массив», когда данные для всех строк получаются одним пакетом до начала цикла оформления.
Посмотрим на влияние антивирусного ПО. При активной работе 40 человек сервер 1С постоянно пишет логи в журнал регистрации. Если антивирус проверяет каждый файл .lgd (SQLite) или .lgp при записи, возникают задержки файловых операций. Необходимо добавить в исключения антивируса:
.mdf, .ldf).snccntxt).1Cv8Log).rphost.exe, rmngr.exe, sqlservr.exe.Если используется версия платформы 8.3.11 и выше, проверьте формат журнала регистрации. Переход на новый формат (SQLite) иногда вызывает блокировки при очень интенсивной записи. В ряде случаев помогает возвращение к старому текстовому формату или сокращение уровня логирования (записывать только ошибки и предупреждения).
Подведем итог. Чтобы победить тормоза при 40+ пользователях, выполним следующие шаги:
MAXDOP = 1 в SQL Server.