koloskovv Apr 29 at 10:21

Записки оптимизатора 1С (ч.11). Не всегда очевидные проблемы производительности на серверах 1С

Easy

12 min

3.7K

SOFTPOINT corporate blog1C*High performance*Microsoft SQL Server*SQL*

Продолжаем обсуждать серверы в контуре высоконагруженных 1С-систем. В предыдущей статье я рассматривал типичные проблемы с серверами СУБД, а сегодня перейдем к серверам 1С. Причем не хочется, чтобы пост превратился в очередной универсальный перечень настроек сервера 1С на все случаи жизни. Поэтому будем смотреть на задачу через призму производительности системы. Главное, сначала увидеть картину целиком, понять причину и, исходя из этого, менять какие-то параметры, пусть те же настройки сервера 1С.

Цель статьи – подсветить несколько достаточно распространенных, но не всегда очевидных проблем производительности ИТ-системы, находящихся на стороне сервера(ов) 1С.

Естественно, я не планирую разбирать очевидные вещи из серии «Хьюстон у нас проблемы. Нагрузка на CPU — 100%, пользователи в истерике». Но начну как раз с CPU :-). Тут есть что рассказать.

Причина 1. Нагрузка на CPU сервера 1С

По процессору будет три примера, в которых счетчик общей нагрузки на CPU будет показывать достаточно низкие значения, но при этом проблема именно в процессоре.

Лицензия ПРОФ (сервер 1С на выделенной машине)

В предыдущей статье я тоже начинал рассказ с ограничений по лицензиям для серверов MS SQL. И сервер 1С не исключение. Итак, ограничения серверной лицензии 1С ПРОФ. Что про нее знаем? Вроде бы информация открытая и на слуху, но тем не менее сталкиваемся с этой ситуацией достаточно часто.

Обратимся к вендору. На рисунке ниже отметил цветом интересующие нас строки:

Лицензия ПРОФ больше 12 ядер CPU использовать не даст. Таким образом, ваш много-многоядерный процессор превращается в двенадцатиядерный. И, как следствие, администратор, если он не в курсе об этом ограничении, увидит на своих мониторах общую нагрузку на процессор заниженной (или даже сильнозаниженной), т.к. системный счетчик будет показывать среднее значение по всем ядрам.

На скриншоте диспетчера задач видно, что 8 из 20 ядер фактически вообще никак не задействованы

Причем еще видно, что основная доля нагрузки на процессор приходится только на два ядра, а остальные нагружены значительно меньше. Это связано с тем, что виртуальная машина, на которой развернут сервер 1С, сконфигурирована таким образом, что ей выделено 10 процессоров по 2 ядра.

А служба сервера 1С, как правило, эффективно работает только с одним процессором (подробнее об этом ниже в разделе NUMA-узлы). Т.е. два ядра будут перегружены, следующие 10 (из 12 возможных для лицензии ПРОФ) почти не нагружены, и остальные 8 (из всех 20 ядер) не нагружены вообще. Но в среднем по больнице будет всё замечательно. И применительно к данной ситуации средняя нагрузка на CPU будет в районе15–20%. Казалось бы, беспокоиться не о чем.

Рекомендация. Если остаемся на ПРОФ, тогда имеет смысл переконфигурировать виртуальную машину — сделать 1 процессор по 12 ядер. Если лицензия обновляется до КОРП, всё равно лучше серверу 1С выделить 1 виртуальный процессор с теми же 20-ю ядрами, т.к. 1С:Предприятие плохо работает с многопроцессорной средой (подробнее ниже).

Описанная ситуация достаточно прозрачная, потому что серверу 1С выделена отдельная машина, на которой ничего больше не работает и в простом диспетчере задач сразу всё видно. Но очень часто на одной машине живут одновременно и сервер 1С, и сервер SQL. И тут ограничение в 12 ядер может быть завуалировано, т. к. обе службы вместе могут нагрузить машину условно равномерно. Рассмотрим такой пример.

Лицензия ПРОФ (на одной машине два сервера: 1С + MS SQL)

Исходные данные:

Возьмем системные счетчики по нагрузке на CPU за пять дней в дневное время (с 9:00 до 18:00).

Как читать такую картинку.

Общая нагрузка на процессор (красный график) высокая и часто переваливает за 80%. Есть 100% пики, но очереди к процессору есть почти всегда и не только в моменты пиков (зеленый график). Это означает что имеет место быть неравномерное распределение нагрузки среди процессорных ядер, когда часть из них испытывает пиковую (максимальную) нагрузку и провоцирует возникновение очередей, а другая их часть оставаться незагруженной.

Посмотрим теперь на оранжевый график, который показывает затраты процессора на обслуживание MS SQL. Изменяется от «0» до «Кол-во процессоров*100». Визуально можно оценить, что более половины ядер (11 шт.) SQL Server не потребляет.

Понятно, что что-то не так с процессором. Следующим шагом можно посмотреть диспетчер задач или распределение нагрузки по каждому из двух виртуальных процессоров. Возьмем маленький интервал в 1,5 часа:

Хорошо видно, что CPU #1 используется более интенсивно и его нагрузка менее 70% даже не опускается. В среднем он нагружен в два раза больше, чем CPU #0. Поскольку нагрузка процесса sql server (оранжевый график) почти никогда не превышает 50%, то получается, что остальные ядра (но не более 12 из-за лицензии ПРОФ) нагружают сервер 1С, и ему их точно не хватает – очереди.

Поэтому в данном случае нужно расширять процессорные ресурсы для сервера 1С. Например, добавить второй сервер с такой же лицензией ПРОФ. И ещё, мы бы рекомендовали при подобном профиле нагрузки в любом случае разносить сервера 1С и SQL по разным машинам, т. к. риск конкуренции за процессорные ресурсы очень велик, а контроль сложен. Понятно, что для ускорения сетевого взаимодействия или имея большие аппаратные ресурсы, есть соблазн использовать не IP, а shared memory для связи сервера приложения и сервера SQL. Но можно легко получить ситуацию с жесткой конкуренцией между службами серверов за эти самые ресурсы. Причем не только за процессорные, но и за память.

NUMA-узлы

Также как и в случае с сервером MS SQL, на сервере 1С тоже есть нюансы работы с NUMA.

NUMA

NUMA (Non-uniform Memory Access или неравномерный доступ к памяти) – системная архитектура для оптимизации эффективности многопроцессорных компьютерных систем. В отличие от однопроцессорных или однородных систем доступа к памяти (UMA), где каждый процессор имеет равный доступ к одному пулу памяти, NUMA настраивает компьютерную систему с несколькими узлами памяти, подключенными к одному или нескольким процессорам. В NUMA-системах память не является общим, однородным ресурсом, а сегментирована и выделена определенным узлам.

Перейду сразу к примеру, чтобы не мусолить теорию.

Исходные данные: Сервер 1С на виртуальной машине, 4 vCPU по 10 ядер, лицензия 1С КОРП, тестовый стенд — мало пользователей (=сессий 1С).

Есть жалоба со стороны пользователя на долгое выполнение операции — десятки часов.

В мониторинге Perfexpert видим, что потребление процессора сервера 1С подозрительно зависло на отметке 50%, и потребляет их всего один(!) процесс rphost:

Аналогичная картина и в диспетчере задач:

Т. е. один rphost уперся в 50% и не может потребить больше CPU.

Если посмотреть теперь в том же диспетчере на нагрузку по процессорам, то увидим интересную картину:

Нагружены под 100% два NUMA-узла. Виртуальная машина создана по принципу 4х10 – четыре vCPU по десять ядер. Итого, в Windows мы видим четыре NUMA-узла, но аппаратных NUMA-узлов на машине два(!) по количестве физических процессоров. И получается так, что один процесс rphost не может масштабироваться за пределы одного же аппаратного NUMA-узла. Отсюда граница в 50%.

Чтобы ее преодолеть нужно, чтобы количество rphos’ов стало хотя бы два.

Количество rphost’ов зависит от количества активных соединений в настройках сервера.

Можно искусственно его ограничить и таким образом обеспечить, чтобы количество rphost’ов будет хотя бы по количеству NUMA, тем самым обеспечив более равномерную нагрузку на CPU. В данном примере речь шла про тестовый стенд, где количество соединений изначально мало и все они «жили» на одном rphos’е и не могли масштабироваться по ядрам.

Собственно, об этом написал сам вендор еще в 2016 году и с тех пор в этой части мало что поменялось:

Игра с изменением количества соединений на процесс может быть не очень хорошей (см. далее), поэтому для серверов 1С имеет смысл держать в голове вариант с отказом от использования технологии NUMA — отключается в BIOS, обычно в разделе по работе с памятью. В этом случае все процессоры и все их ядра будут для Windows одним NUMA-узлом.

Причина 2. Нехватка портов для сервера 1С

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

Стандартный диапазон — это 1560..1591, то есть 32 порта или не более 32-х процессов rphost.

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

При проверке системных счетчиков ничего не обнаружено — процессор, память, диски, тяжелые запросы, лицензия — всё хорошо.

Но если построить график количества активных рабочих процессов, то видно, что за исследуемый интервал это значение достигало дважды магической цифры 32, а также не раз было близко к этому.

Из-за использования максимального количества портов в системе могут возникать ситуации, когда все существующие процессы rphost заняты обслуживанием других соединений, а соединение вынуждено ожидать освобождения места в пуле уже запущенных рабочих процессов, т. к. создание нового rphost невозможно. Соответственно пользователи 1С могут испытывать зависания, а при массовых сбоях — ошибки повторного подключения к ИБ. Также стоит заметить, что даже если порт свободный есть, пользователь может ожидать какое-то время пока запустится новый rphost, и оно может длиться более 10 секунд, т. к. каждый rphost тянет за собой загрузку всей конфигурации 1С.

Для стабильной работы кластера 1С должно быть свободно хотя бы 3-4 порта для создания новых рабочих процессов.

Из-за чего происходит переполнения стэка портов? Чаще всего из-за того, что в настройках сервера 1С указывают слишком маленькое количество соединений на процесс, например, 25 как на рисунке ниже при значении по умолчанию 256. Обычно это аргументируют тем, что если rphost «упадет», то больше 25-ти соединений не пострадает.

Всегда нужно искать разумный баланс между количеством соединений на процесс и количеством самих процессов, чтобы накладные расходы на межпроцессное взаимодействие, «перебрасывание» соединений между процессами, на запуск самих процессов и потребление ими памяти не дали бы обратный эффект. Но в целом, если вы часто упираетесь в лимит портов, то их диапазон можно расширить, это не проблема, но нужно только правильно оценить необходимость этого.

Причина 3. Доступная производительность

Выше я упомянул про «перебрасывание» соединений между процессами. Остановимся на этом чуть подробнее.

У каждого рабочего процесса на сервере приложений есть счётчик доступной производительности.

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

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

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

При снижении доступной производительности кластер 1С пытается перераспределить сеансы пользователей между рабочими процессам. По нашему опыту работы можем заключить, что счётчик доступной производительности не должен опускать ниже значения – 100.

В моменты когда доступная производительность опускается до низких значений, пользователи 1С могут сталкиваться либо с ожиданиями пока их сеансы будут переброшены на другой rphost, либо с ошибками типа «На сервере 1С:Предприятие произошла неисправимая ошибка...».

Имеет смысл держать хотя бы один резервный рабочий процесс, который является неактивным и в случае сбоя одного из активных процессов возьмет его соединения на себя, но от задержки «первого входа» он не спасает.

Хочу показать как выглядит переключение соединений с одного rphost на другой. На рисунке – счетчики количества соединений на четырех разных процессах rphost.

В какой-то момент (выделен желтым) rmngr решил, что rphost #1 и rphost #3 не справляются со своей задачей и их соединения нужно перебросить на другие процессы. Соединений на каждом процессе много (по ~250) и нужны как минимум два новых процесса. Процесс rphost #4 существовал до этого, на нем были какие-то соединения, но не в большом количестве, и он довольно быстро наполнился переброшенными соединениями – рост графика почти вертикальный. А вот процесс rphost #2 был создан, и рост соединений на нем достаточно плавный. Я не разбираю здесь причины происходящего, просто показал, что переключение пользователей с процесса на процесс не всегда бесшовное и может сопровождаться зависаниями, а иногда и ошибками. По нашему опыту, снижение показателя доступной производительности почти всегда связано с какими-то проблемами на стороне процессора. Поэтому, если вы столкнулись с падением доступной производительности, начинайте разматывать проблему с процессора.

Причина 4. Утечка памяти в rphost

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

Приведу пример у заказчика с утечкой памяти после смены релиза платформы.

Смотрим на три розовых графика, которые показывают свободную оперативную память на сервере приложения. Триграфика — три сервера приложения. Утечка происходила не быстро, на протяжении 2–3 дней. Но как только уровень свободной оперативной памяти падал меньше 20 Гб, начиналась сильная просадка производительности и приходилось вручную перезапускать серверы 1С. Причиной является то, что один или несколько rphost’ов не высвобождают память:

Потребление памяти процессом rphost может быть как плавным, так и скачкообразным — на розовых графиках есть характерные кратковременные провалы. Для борьбы с таким явлениями нужно искать причину — конкретный пользовательский сеанс, который к этому привел.

В Perfexpert можно вывести сессии по каждому процессу rphost и найти такие сеансы:

Для этого я спозиционировал линейку времени на одном из таких провалов (05.03.25 в 12:30) и в окне сессий 1С видно, что пользователь Ром*** отъел почти 19,5 Гб, а весь процесс rphost съел 30,5 Гб. Также видно, что пользователь Ром*** запускал в этот период отчет «История о…» — см. колонки «Форма» и «Модуль». Источник проблемы найден. А причина, скорее всего, в огромной выборке данных (запрос без фильтров, за большие периоды и т. п.), на обработку которых потребовался столь большой объем памяти. Исправляется на уровне 1С — запрет для пользователей получать отчеты без фильтров. В противном случае даже один пользователь имеет все шансы уронить систему.

Для борьбы с «плавным» снижением свободной оперативной памяти применяется перезапуск рабочих процессов, либо ограничение памяти, выделяемой каждому процессу. Последнее ограничение может привести к ошибкам при обновлении больших конфигураций 1С и его лучше использовать выборочно по времени, либо зная наперед максимальный размер процесса при таких операциях.

После установки интервала перезапуска раз в сутки (86 400 сек) и ручного перезапуска серверов, чтобы этот момент стал точкой отчета для «86400 сек» ситуация нормализовалась. На рисунке ниже показаны счетчики по одному из трех северов 1С:

Розовый график — счетчик свободной оперативной памяти, а синие графики — это потребление памяти отдельными процессами rphost (показал несколько штук для понимания динамики). Таким образом, в первой половине дня происходит перезапуск процессов rphost, объем свободной оперативной памяти поднимается и постепенно падает в течение суток.

Итого

Обобщу вышесказанное. Это, конечно, далеко не всё, что можно рассказать про настройки серверов 1С. Но я выделил те примеры, которые не так очевидны, потому что далеко не все инструменты диагностики позволяют обнаружить, в чём кроется истинная причина проблемы.

Напомню, обсуждали сегодня причины просадки производительности серверов 1С, которые не видны сразу на стандартном наборе счетчиков производительности.

Нагрузка на CPU сервера 1С. Точнее, разбалансировка нагрузки по ядрам процессора.
Внешние признаки: нагрузка по большей части не поднимается выше какого-то порога, фиксируются очереди, которых быть не должно при такой нагрузке.
В первую очередь проверяем лицензию 1С на сервере 1С. Если это ПРОФ, то у вас гарантированное ограничение на использование только 12 ядер. Кроме того, необходимо проверить как настроены NUMA-узлы на сервере и как распределена нагрузка по ним. 1С:Предприятие не всегда корректно работает с NUMA, и может такое случиться, что часть NUMA-узлов (ядер) на вашем сервере остается недоиспользованными, а другая часть будет перенапрягаться. Для устранения дисбаланса можно вообще отказаться от NUMA (идём в настройки BIOS), либо можно попробовать поиграться настройками сервера 1С и выставить такое количество соединений на процесс, чтобы количество rphost’ов было бы не менее количества NUMA-узлов.
Нехватка портов для создания необходимого количества процессов rphost.
Проблема не всегда очевидная. У пользователей возникают непонятные залипания и ошибки повторного запуска 1С.
В настройках сервера 1С по умолчанию указывается пул портов 1560:1591, которые позволяет создать 32 процесса rphost.
Вы можете создать счетчик в вашей системе мониторинга, который будет отслеживать количество процессов. И если оно будет приближаться к этой цифре, то имеет смысл превентивно либо расширять диапазон, либо увеличивать количество соединений на один процесс. Но сначала лучше разобраться почему так происходит и к чему могут привести изменения в настройках, чтобы не парализовать систему.
Утечка памяти. Не самая частая проблема, но и не самая редкая.
Выражается в снижении свободной оперативной памяти до критически низких значений. Приводит к падению производительности как сервера 1С, так и других приложений на сервере. Причиной обычно является значительное потребление памяти одним или несколькими rphost’ами, которую они не высвобождают.
Если потребление скачкообразное и объем свободной памяти возвращается примерно на тот же уровень, то необходимо искать конкретного пользователя (сеанс), который явился причиной резкого потребления памяти и понять его действия.
«Плавное», но постоянное снижение свободной оперативной памяти устраняется однократным перезапуском сервера 1С и установкой регулярного перезапуска процессов в настройках сервера 1С (раз в сутки).

Для мониторинга второй и третьей проблемы будет полезно использовать значения доступной производительности по каждому активному процессу rphost. Если оно ниже 100 - 120, то это явный маркер, что что-то не так с этими процессами.

Надеюсь, статья получилась полезной. Если у вас есть свои примеры неочевидных проблем и решений к ним, будет любопытно ознакомиться.

Ссылки на остальные части Записок оптимизатора 1С:

Tags:

Hubs: