← На главную

При администрировании высоконагруженных систем на базе 1С:Предприятие 8 системные администраторы часто сталкиваются с мониторингом производительности серверной части. Одним из ключевых показателей в системном мониторе Windows (Performance Monitor) является Processor Queue Length (длина очереди процессора), а в технологическом журнале 1С — параметр OSThread. В этой статье мы подробно разберем, как связаны эти понятия, как платформа 1С взаимодействует с ресурсами процессора и почему простое увеличение количества ядер не всегда решает проблемы производительности.

Природа потоков OSThread в 1С

Для начала проанализируем, что именно мы видим в технологическом журнале 1С. Когда рабочий процесс rphost выполняет какую-либо операцию (запрос клиента, запуск фонового задания), в логах фиксируется идентификатор OSThread. Рассмотрим ситуацию: сервер имеет 4 ядра, и мы видим появление нового потока JobScheduler, после чего очередь к процессору резко возрастает.

Важно понимать, что 1С не "изобретает" собственную систему управления низкоуровневыми потоками. Параметр OSThread — это стандартный Win32 thread (поток операционной системы). Платформа делегирует управление этими потоками ядру Windows. Это означает следующее:

1. Распределение по ядрам: Операционная система сама решает, на каком физическом или логическом ядре будет выполняться конкретный поток.
2. Миграция потоков: Поток может быть переброшен с одного ядра на другое в процессе выполнения. Это особенно заметно при использовании сбалансированных схем электропитания, когда ОС пытается оптимизировать энергопотребление.
3. Контекстное переключение: Если потоков больше, чем ядер, ОС постоянно переключает процессор между ними, что создает ту самую "очередь".

Механизм пула потоков и влияние JobScheduler

Разберем подробнее ситуацию с JobScheduler. Этот поток является системным механизмом внутри rphost, который отвечает за мониторинг таблицы регламентных заданий. Сам по себе он не потребляет много ресурсов, но его активность служит триггером. Как только JobScheduler определяет, что пришло время для выполнения задач, платформа инициирует запуск фоновых заданий.

В современных версиях 1С реализован пул потоков. Рассмотрим, как это работает по шагам:

1. При поступлении новой задачи (например, фонового задания) платформа проверяет наличие свободных потоков в пуле.
2. Если свободный поток есть, задача назначается ему.
3. Если все потоки заняты, создается новый OSThread (до достижения определенных лимитов настроек кластера).
4. Именно в момент массового "пробуждения" или создания потоков для фоновых заданий мы и видим всплеск Processor Queue Length. Это происходит потому, что множество потоков одновременно переходят в состояние готовности (Ready) и требуют процессорного времени.

Масштабирование: почему 8 ядер не всегда лучше 4-х

Рассмотрим часто возникающий вопрос: если увеличить количество ядер с 4 до 8, разгрузится ли очередь? Проанализируем эту ситуацию с точки зрения архитектуры 1С. Теоретически, большее количество ядер позволяет обрабатывать больше потоков одновременно, что должно сократить время нахождения потока в очереди. Однако на практике масштабирование в 1С происходит нелинейно.

Выделим основные причины, по которым добавление ядер может не дать ожидаемого эффекта:

1. Тактовая частота против количества ядер. Многие операции в 1С выполняются последовательно в рамках одного потока. Рассмотрим пример: один тяжелый расчет на процессоре с частотой 4 ГГц выполнится быстрее, чем на процессоре с 2 ГГц, даже если во втором случае ядер будет в два раза больше. Для 1С частота одного ядра зачастую критичнее их общего количества.

2. Пропускная способность памяти. С ростом количества потоков возрастает нагрузка на шину памяти и кэш-память процессора (L3 Cache). Если 8 ядер будут делить тот же объем кэша и тот же контроллер памяти, что и 4 ядра, возникнет "узкое место" на уровне обмена данными, и очередь не уменьшится.

3. Программные блокировки (LATCH). Выясним причину, почему поток может висеть в очереди, даже если процессор свободен. Внутри процесса rphost существуют общие области памяти. Если один поток заблокировал ресурс для записи, остальные потоки (даже на свободных ядрах) будут ждать освобождения этой блокировки. В системном мониторе это также может отражаться как ожидание.

Практические рекомендации по настройке

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

Режим электропитания

Для серверов 1С критически важно установить схему "Высокая производительность" (High Performance). В сбалансированном режиме ОС может "парковать" ядра или снижать их частоту. Когда JobScheduler дает команду на запуск заданий, требуется время (миллисекунды) на "разогрев" ядер, что вызывает мгновенные скачки очереди.

Настройка количества рабочих процессов

Вместо того чтобы раздувать один процесс rphost на огромное количество потоков, иногда эффективнее распределить нагрузку. Разберем параметры в консоли администрирования кластера:

• Количество соединений на процесс — ограничение этого параметра заставит систему создавать новые rphost.
• Это позволяет уменьшить конкуренцию потоков за кучу (heap) и внутренние объекты синхронизации одного процесса.

Hyper-Threading и виртуализация

Посмотрим на ситуацию в среде виртуализации. Если вы используете VMware или Hyper-V, показатель очереди внутри гостевой ОС может быть неточным. Важно проверять параметр CPU Ready на уровне гипервизора. Также во многих высоконагруженных внедрениях рекомендуется отключать Hyper-Threading на физическом уровне, так как 1С выполняет тяжелые вычисления, и два логических потока на одном физическом ядре могут мешать друг другу, увеличивая время обработки каждого OSThread.

Резюме

Мы выяснили, что потоки 1С — это обычные потоки операционной системы. Их количество и поведение напрямую зависят от интенсивности фоновых заданий и клиентских запросов. Для эффективной борьбы с очередями процессора необходимо соблюдать баланс между количеством ядер, их тактовой частотой и правильной настройкой количества рабочих процессов 1С.