Обработка на Инфостарте
Самый нагруженный процесс не всегда виноват
Он просто самый заметный. Пока вы не построили временной ряд подозреваемого, у вас не диагноз, а гипотеза с хорошей репутацией.
Обработка платная, 10 SM. Если сервер тормозит регулярно и причина каждый раз новая, мы разбираем это как работу: с замером до и после.
История, из которой выросла обработка. Сервер приложений грузил процессор, нагрузку разложили по процессам, нашли главного потребителя и назвали его причиной. Заказчик возразил одной фразой: этот процесс всегда работал столько же.
Проверка заняла пять минут. Построили ряд числа запусков по суткам за двенадцать дней: 264, 271, 265, 267, 262, 269, 265, 272, 264 тысячи. Среднее около 266,6 тысячи, разброс полтора-два процента. Это константа, а константа не может объяснить изменение, которое началось в конкретный день.
Дальше было ещё шесть кандидатов, и каждый выглядел убедительно ровно до момента, когда его проверяли числом. Обработка делает это быстро: снимает нагрузку по процессам, сеансам и базам и показывает, кто держал блокировки и кто потреблял процессор в интересующем окне.
Что она даёт
Раскладку нагрузки по источникам
Процессы, сеансы, базы и фоновые задания: кто сколько потребил, а не общая цифра по серверу.
Кто держал блокировки
Вопрос "кто заблокировал базу" отвечается конкретным сеансом и конкретным объектом, а не предположением.
Материал для временного ряда
Главная ценность не в срезе, а в возможности сравнить срезы между собой. Кандидат, который вёл себя одинаково до и во время деградации, из подозреваемых выбывает.
Правило, ради которого это писалось
Стенд, на котором собран пример: двухузловой кластер, восемь логических ядер, три базы, порядка 645 сеансов.
| Показатель | Значение | Как надо | Вердикт | Что это значит |
|---|---|---|---|---|
| Запусков обмена в сутки, 12 дней | 264-272 тысячи | разброс менее 2 % | инфо | коэффициент вариации около 1,2 %, то есть поведение не менялось |
| Вывод по кандидату | снят с подозрения | - | норма | константа не объясняет изменение, начавшееся в определённый день |
Разбор результата
Честно скажу, чем кончилась та история: метод довёл до конкретного объекта и до конкретного часового окна, а корневую причину в том разборе так и не назвали. Ценность здесь в способе искать, а не в готовой развязке.
Порядок работы
- 01
Снять раскладку в момент проблемы
Нужен срез именно тогда, когда плохо. Срез на здоровой системе пригодится позже как база для сравнения.
- 02
Выписать кандидатов
Обычно их три-семь, и каждый выглядит убедительно. Это нормально и это ловушка.
- 03
По каждому построить ряд
Сравнить поведение до деградации и во время. Всё, что вело себя одинаково, из списка вычёркивается.
- 04
Оставшихся проверять глубже
После вычёркивания констант список обычно сокращается до одного-двух, и с ними уже имеет смысл разбираться детально.
Өзіңіз шеше алмай жатырсыз ба? Жазыңыз, бірге қараймыз
1С кластері мен ДҚБЖ бойынша Grafana дашбордтары, проблема кезінде Telegram-ға алерттер. Ақау туралы пайдаланушылардан бұрын білесіз - ал деградацияны аварияға дейін апталар бұрын көресіз.
- Құны
- 450 000 ₸-дентолық ендіру; салықтарсыз
Тақырып бойынша талдаулар
Сервер 1С грузит процессор: как найти причину и не обвинить не тот процесс
Порядок поиска причины, когда сервер 1С грузит процессор, а в диспетчере задач сверху rmngr или rphost. Проверки расставлены по цене: от накопленного времени ЦП и часового ряда по журналу регистрации до технологического журнала и поиска сервиса внутри менеджера кластера без перезапуска агента. С готовыми скриптами PowerShell и рабочим фильтром техжурнала.
Кто блокирует базу 1С: найти виновника сейчас и восстановить, кто держал ночью
Когда база встаёт, вопрос звучит одинаково: кто её держит. Ответ на него собирается за пять минут тремя способами - консолью кластера, командой rac и запросом к СУБД, и у каждого способа своя слепая зона. Хуже другое: к моменту, когда вы открыли консоль, виновник обычно уже отпустил замок, и на вопрос про ночь снимок текущего момента не отвечает вовсе. Разбираем оба случая: как назвать держателя по имени прямо сейчас и как устроить историю снимков, по которой утром видно, кто держал базу с двух до четырёх.
Рабочий процесс 1С растёт по памяти: как это замерить и что выставить
Порядок действий для случая, когда rphost растёт и не отдаёт память. Сначала как убедиться, что это действительно он, а не ошибка чтения метрик: суточный максимум показывал по диску 97-99 % при среднем 4,24 %, а прореженный ряд одновременно прятал провалы свободного места до 27 мегабайт. Дальше готовые скрипты сбора и расчёта наклона, четыре свойства кластера с правилами выбора значений, команды rac и проверка трёх таймаутов терминальных сеансов, которые держали десять гигабайт впустую.
1С висела, серверы перезагрузили: какие следы аварии остались и сколько они живут
После перезагрузки SQL Server и кластера 1С большая часть улик пропадает сразу, остальная через дни. Разбираем по источникам, что где хранится и когда стирается, что успеть сохранить за две минуты до рестарта, как по журналу регистрации доказать, что беда общая для всех баз, как читать события vCenter голым SOAP и что поставить заранее, чтобы следующую аварию было по чему разбирать. Иллюстрация - зависание касс в рознице, где через три недели назвать виновника было уже нечем.
Рядом по теме
Жиі қойылатын сұрақтар
Она показывает только того, кто держит блокировку сейчас?
Она показывает, кто держал базу за выбранный период. Для этого копится история снимков: держатель блокировки пишется в неё вместе с жертвами, и по номеру его сеанса видны пользователь, компьютер и приложение.
Как копится история, если никто не нажимает кнопку?
Обработку добавляют в штатный список "Дополнительные отчёты и обработки" и ставят расписание команде "Собрать данные о кластере", рекомендуется раз в 5 минут: счётчики нагрузки в 1С пятиминутные. Снимки ложатся файлами JSON на диск сервера, старые удаляются по глубине хранения и потолку объёма.
Что нужно для запуска?
Платформа 8.3.14 и выше, любая конфигурация и работающий сервер администрирования RAS, а rac.exe, COM и внешние компоненты не нужны. Если RAS не поднят, в комплекте bat-файл: он сам запросит права администратора и возьмёт ras.exe той версии, на которой работает кластер. Проверена на 8.3.20 и 8.3.27.
Обработка обращается к СУБД или пишет в базу?
К СУБД не обращается вообще и в прикладные объекты конфигурации не лезет. История пишется файлами в каталог на диске, а свои настройки обработка держит в хранилище общих настроек базы: так их видят и форма, и регламентное задание.
У нас несколько рабочих серверов за балансировщиком. Заработает?
Да, на таком кластере она проверена. Каталог истории укажите сетевой папкой, доступной на запись всем узлам под учётной записью службы сервера 1С. Иначе снимки разложатся по разным узлам, и данные будут то появляться, то пропадать.
Чего она не делает?
Технологический журнал и журнал регистрации она не разбирает, метрики во внешний мониторинг не отправляет. Кластером не управляет: сеанс не завершит и соединения не заблокирует. Её работа - история нагрузки по данным сервера администрирования.
1С жүйеңізге тегін экспресс-аудит
1-2 күнде базаңызды қарап, өнімділік қайда жоғалып жатқанын табамыз және не істеу керегін айтамыз. Міндеттемесіз.
Тапсырманы талқылайық
Ең жылдамы WhatsApp: тапсырма туралы бірер жол жазыңыз, жұмыс күні ішінде жауап береміз.