Как посмотреть кто грузит сервер 1с
Один из серверов 1С, который я обслуживаю, очень странно себя вел. Загрузка процессора на машине с сервером 1С почти всегда была 100%, даже когда на нем никто не работал. Базы хранились в MSSQL, их было относительно много, но реально людей, которые с ними работали - мало. Одновременно работало не больше 10-15-ти пользователей в очень вялом режиме.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на . Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.Введение
Этот сервер привлек мое внимание сразу же, как только я стал с ним работать. Предыдущий администратор безрезультатно бился над производительностью, приобрел 2 внешних корзины для отдельного рейда под базы данных mssql и временные данные пользователя 1С, но существующую проблему по загрузке процессора это не решало, хотя немножко разгрузило диски, но реальная проблема была не в них.
На сервере размещались примерно 30-35 баз, в которых работали по 1-2 человека и пару баз были, где работали по 3-5 человек одновременно. Все это крутилось вместе с MSSQL сервером на отдельном железном сервере с одним стареньким ксеоном и 32 гб оперативы. В принципе, для этих задач железо было более чем.
Первое, на что я обратил внимание, это то, что процессор был загружен даже ночью, когда на сервере никто не работал. Полез в консоль администратора смотреть, что нагружает процессор. Оказалось, что это фоновые задачи. Для большинства баз они были не нужны и все лишнее отключил. Нагрузка процессора сразу упала до приемлемого уровня в 60-70%, а диски вообще полностью разгрузились. Я про сервер забыл на какое-то время.
Снова к нему вернулся, когда пользователи стали жаловаться на очень медленную работу баз 1С. Процессор к тому времени почти всегда был загружен на 100%. Лишних фоновых задач уже не было. Надо было разбираться более внимательно, в чем тут проблема.
Разбираемся что конкретно в rmngr.exe грузит процессор
Загрузку процессора в равной степени давал процесс rmngr.exe и rphost.exe. Rphost уже ранее был настроен и оптимизирован. Вот такие настройки дали стабильную работу без необходимости перезапускать сервер месяцами:
Нагрузку rphost давал за счет оставшихся фоновых задач и что с ним еще сделать, я не знал. А с rmngr хотелось разобраться и узнать, что конкретно пожирает процессорное время. В этом процессе собраны все процессы менеджера кластера:
Есть возможность разделить сервисы менеджера кластера по разным системным процессам rmngr.exe и по pid определить, какая именно служба нагружает процессор. Включить такое разделение можно в свойствах рабочего сервера:
После того, как вы поставите галку, агент сервера 1С сам перезапустится с новыми настройками. После этого в диспетчере задач у вас будет порядка 15-ти процессов rmngr.exe с разными pid. Смотрите, какой из процессов больше всего использует процессор и в консоли управления 1С в разделе Менеджеры кластера по pid смотрите описание процесса.
В моем случае это был сервис журнала регистраций. Чтобы это узнать, дважды щелкните мышкой по процессу с необходимым pid:
Пол дела сделали, нашли виновника тормозов. Я скрины делал, когда уже решил проблему, так что у меня нагрузки нет.
Сервис журнала регистраций 1С нагружает процессор
Я выяснил, что конкретно дает чрезмерную нагрузку на сервер. Посмотрел на объем журналов регистраций. У некоторых баз он достигал размера в 10-15 гигов. После чистки серверу стало заметно легче, нагрузка снова опустилась, но где-то до 80-90% и я на несколько месяцев забыл про сервер.
Он напомнил о себе тормозами и загрузкой процессора в 100%. Проделанные выше операции уже не давали результата. Баз стало немного больше и нужно было думать, как разгрузить сервер. Он работал на все 100% даже в нерабочее время, когда на нем не было ни одного реального пользователя. Сервис журнала регистраций потреблял 30-40% процессорного времени.
Я стал внимательно шерстить интернет на заданную тему и нашел несколько заметок. Находились люди, которые обратили внимание на чрезмерную нагрузку сервиса журнала регистраций. Как вариант решения проблемы они предлагали откатиться на старую версию ведения логов lgf вместо новой lgd. Я не знаю, что принципиально изменилось в формате ведения лога журнала регистраций, но по отзывам попробовавших, нагрузка на процессор падала. Забегая вперед скажу, что мне этот совет помог.
Переводим сервер на старый вариант ведения логов журнала регистраций
В каждой папке с базой есть каталог 1Cv8Log, а в нем 2 файла: 1Cv8.lgd и 1Cv8.lgd-journal. Их надо удалить и вместо них в этой папке создать пустой файл 1Cv8.lgf. Проделать такую операцию нужно со всеми базами, где будете менять формат лога. Старый не обязательно удалять, лучше его перенести куда-нибудь, вдруг пригодятся записи из него.
После этого можно запускать службу Агента Сервера 1С:Предприятия. После перехода на старый формат журнала регистрации, нагрузка процесса rmngr.exe упала практически до 0, а сервера в целом до приемлемых 40-60%.
Заключение
После того, как вы решите все проблемы на сервере 1С, процессы менеджера кластера нужно снова объединить в 1, убрав отвечающую за этот параметр галку в свойствах рабочего сервера. 1С не рекомендует постоянно использовать такой режим работы, так как он является отладочным.
Значительное потребление памяти процессами кластера на сервере приложений
У кластера серверов 1С Предприятия есть несколько настроек перезапуска процессов по превышению порога памяти. Их можно найти в параметрах кластера в консоли администрирования(рис. 1).
Рис. 1. Параметры кластера.
Подробная информация по настройкам указана на странице ITS.
Рекомендуется всегда настраивать параметры
- Допустимый объем памяти
- Интервал превышения допустимого объема памяти
- Выключенные процессы останавливать через
"Допустимый объем памяти" стоит устанавливать из расчета, того, что в случае срабатывания условия превышения показателя будет запущен ещё один процесс rphost того же объема, как при нормальной работе кластера серверов в этой информационной системе.
Например, на рабочем сервере имеем 12 Гб ОЗУ. Допустим для конкретной информационной системы характерен размер rphost около 3 Гб. В этом случае порог превышения памяти следует рассчитывать следующим образом:
"Допустимый объем памяти" = 12 ГБ - 2 Гб (объем, занимаемый процессами системы) - 3 Гб * 1 rphost (объем всех процессов rphost) = 7 Гб. Т.е. процесс rphost в худшем сценарии может вырасти до 7 Гб.
Для случая, когда у нас при штатной работе используются два процесса rphost.
"Допустимый объем памяти" = 12 ГБ - 2 Гб (объем, занимаемый процессами системы) - 3 Гб * 2 rphost (объем всех процессов rphost) = 4 Гб. Т.е. процесс rphost в худшем сценарии может вырасти до 4 Гб.
Такая рекомендация исходит из особенностей поведения в момент перезапуска процессов кластера. Как это происходит:
- процесс rphost превышает "Допустимый объем памяти" в течение "Интервал превышения допустимого объема памяти" секунд, срабатывает условие перезапуска процессов кластера.
- запускается "новый" процесс rphost
- "старый" процесс rphost выключается, но не завершается
- соединения назначаются на "новый" процесс rphost, который сразу полноценно включается в работу
- "старый" процесс будет исполнять вызовы (которые ещё существуют) максимум в течение ещё "Выключенные процессы останавливать через" секунд, но не более того.
- через время "Выключенные процессы останавливать через" "старый" процесс rphost завершается.
- новый процесс полноценно работает
Т.е. в течение периода, указанного в "Выключенные процессы останавливать через" будет одновременно работать как минимум два процесса rphost: "старый" и "новый".
Не следует указывать "Допустимый объем памяти" меньше нормального рабочего объема памяти процесса rphost для вашей системы, т.к. противном случае у вас постоянно будут перезапускаться процессы кластера серверов.
- Интервал превышения допустимого объема памяти
- Выключенные процессы останавливать через
следует стараться указывать как можно меньше исходя из характера нагрузки на информационную систему, например, по 60 секунд, если мы рассчитываем, что все операции (или большая их часть) должны выполниться быстрее 60 секунд.
Чем больше значения указанных параметров, тем менее эффективен может оказаться механизм перезапуска процессов, но зато позволит "успешно выполнить" большее число вызовов.
Высокая загрузка CPU на сервере СУБД MS SQL Server
Наблюдаем высокую загрузку CPU по счетчикам Processor Time на сервере СУБД c MS SQL Server.
Что делать?
Симптом
Видим высокую загрузку CPU на сервере MS SQL Server.
Загрузку видим "сейчас", при этом по данным Performance Monitor, Диспетчера задач или Монитора ресурсов мы уверены, что основную нагрузку создает именно MS SQL Server.
Что требуется сделать
Существует два подхода к получению ответа на вопрос: "Почему и что именно создает такую нагрузку".
Каждый из подходов может оказаться полезным.
Рекомендуется проделать действия, указанные в двух подходах, и применять на практике тот (либо их комбинацию ), который более других подойдет к вашей ситуации.
Например, можно настроить технологический журнал с фильтрами только на один запрос. Может выглядеть так:
Смысл в том, чтобы указать такие фильтры
которые будут включать имена таблиц в найденном вами на предыдущем шаге запросе.
Если всё аккуратно сделаете, то в полученном технологическом журнале запрос у вас будет только тот, который нужен.
Журнал получится небольшим.
Собственно стек из кода на встроенном языке будет сразу в конце события с запросом.
Top запросов, создающих нагрузку на CPU на сервере СУБД за последний час
Нагрузка на CPU по базам
Наибольшая нагрузка на CPU
Наиболее часто выполняемые запросы
Индексы с высокими издержками при использовании
Подход 2
Подключиться к серверу СУБД. Запустить MS Sql Server Management Studio
Выяснить, какие именно базы создают наибольшую нагрузку на сервер СУБД за последний период (в течение которого наблюдается нагрузка). В этом примере период 1 час '01:00:00.000', его нужно будет изменить.
Получаем список запросов, которые создали нагрузку за последний час, посчитанный по 10000 запросов. (Выполняется около 2 минут).
В первую очередь смотрим на percent_worker_time и percent_elapsed_time. Нагрузка не должна быть «размазана» между всеми запросами.
4.1. Если нагрузка "размазана" по запросам, нужно настраивать трассировку
4.1.1. Для этого на сервере должна быть директория для трассировки.
Нужно директорию указать вместо 'InsertFileNameHere' в скрипте ниже.
Размер файла трассировки ограничен 1 Гб.
4.1.2. Останавливаем трассировку, когда уверены, что трассировку собрали в интересующий период нагрузки.
4.1.3. Сохраняем трассировку в тестовую БД test в таблицу trace, в которой будем анализировать загрузку.
4.1.4. Добавляем в таблицу trace две колонки HashSQL varchar(4000) и HashSQLMD5 varbinary(32).
В качестве альтернативы для этих целей можно использовать курсор:
4.1.5. Анализируем трассировку. Например, смотрим:
Находим наиболее интересные запросы по SUM([CPU]).
В целом эту же методику можно использовать для поиска по Reads, Writes, Duration, и т.д.
4.1.6. Для того, чтобы найти запрос в коде конфигурации настраиваем тех журнал вида
указываем ключевые слова из запроса.
4.1.7. По технологическому журналу определяем лидера, исправляем.
4.2. Если есть явный лидер, лучше начать с этого лидера и повторить алгоритм.
4.2.1. Для того, чтобы найти запрос в коде конфигурации настраиваем тех журнал вида
указываем ключевые слова из запроса.
4.2.2. По технологическому журналу определяем лидера, исправляем в коде конфигурации.
В собранном технологическом журнале будет искомый запрос с указанием стека на встроенном языке, "откуда" этот запрос выполнялся.
Стандартный вызов при администрировании систем 1С – проблема отношений между процессором сервера (CPU) и рабочим процессом rphost.exe, который обслуживает клиентские обращения и взаимодействует с сервером базы данных. Нередко они становятся причиной перегрузок CPU, что приводит к замедлению и сбоям работы. Разбираемся, как выявлять такие случаи и что делать для их профилактики и устранения.
Начнём с того, что rphost представляет собой ключевое звено всей архитектуры 1С, забирая на себя большую аппаратную нагрузку. Процессов rphost может быть много по разным машинам внутри корпоративной системы 1C. При этом rphost.exe часто «съедает память» и перегружает процессор. К примеру, это может выглядеть так:
Дано
- сервер 1С: Wndows Server 2016 Standard, 32 Гб ОЗУ, 12-ядерный процессор 2.7 ГГц;
- платформа 1С — 8.3.15.1565 с настройками по умолчанию;
- 60 баз, лицензия платформы ПРОФ.
Проблема
Процессор загружен постоянно на 85-100% (и каждое ядро, и суммарно). Требуется выявить причину такой загрузки и разгрузить процессор.
Решение
Начинаем с самого простого и очевидного. Откроем диспетчер задач Windows, вкладку Details и отсортируем список процессов по колонке CPU.
Если видим один или несколько процессов rphost.exe в топе – значит, процессор загружен 1С. Если процессор загружен, значит какие-то задачи выполняются. А так как процессор загружен слишком часто, то задачи выполняются либо слишком долго, либо слишком быстро и часто.
Но что именно может суммарно выполняться настолько долго в 1С, что это становится проблемой? Находим топ суммарно длительных серверных вызовов. Для этого нам понадобится выполнить сбор технологического журнала (ТЖ). Это специальный механизм платформы 1С 8.3, который позволяет протоколировать все события, происходящие в системе, в том числе системные ошибки.
Настройка его сбора выглядит так:
Далее необходимо провести парсинг собранного для выявления возможных источников проблемы. В этом поможет следующий скрипт:
С помощью GitBash в директории ТЖ запускаем скрипт. Получаем следующий результат:
В топе оказались регламентные задания. Заходим в базы и проверяем периодичность каждого регламентного задания. Периодичность высокая.
1. Если в работе системы 1С компании есть период нерабочего времени, переносим время запуска на него.
2. В случае, когда нерабочего времени нет (система всегда работает), уточняем, пользуются ли пользователи полнотекстовым поиском. Если нет — отключаем регламентные задания. Если да — уточняем допустимый предел актуальности данных (например, на вчерашний день, двухчасовая актуальность). И меняем периодичность запуска соответственно.
3. Проблему это не решает, если пользователь отвечает, что порога актуальности быть не должно или он должен быть слишком мал, как в примере. Тогда полнотекстовый поиск требуется выполнять только по определённым таблицам, полям. В таком случае для остальных полей требуется отключить свойство использования полнотекстового поиска.
4. Наконец, самый сложный случай, когда полнотекстовый поиск требуется для всех полей, а данные меняются часто. Тогда для решения потребуется либо произвести увеличение количества ядер (и желательно их частоты), либо выполнить перенос сервиса полнотекстового поиска на отдельный сервер.
5. Также иногда проблему загрузки процессора решают довольно банальные шаги: перезагрузка сервера и обновление платформы. Работа с актуальными версиями платформы имеет смысл по многим причинам, одна из которых — постоянный поиск разработчиками путей по снижению системных требований для работы 1С.
Читайте также: