Добрый день

Может есть знающие спецы, кто сталкивался с подобной проблемой. Из-за чего может идти нагрузка на CPU у rphost?
Точнее как определить, что так стало нагружать процессор у rphostов? Есть какая-то методика выявления?

Искать по CpuTime в ТЖ мне не подходит, т.к. старая платформа (обновить не предлагать, не тот случай!)

Это https://its.1c.ru/db/metod8dev/content/5814/hdoc конечно же не мой случай

Как до CpuTime определяли, что грузило проц у rphosta?

у rphosta проц скачет от 1-2% до 50%. Т.е. нет такого, что он уперся в 50% и постоянно грузит его. Идет именно скачками. Какой-то зависимости от времени нет, больше всего это в рабочее время. но и в ночное время, когда народу мало работает, apdex так же стал проседать, чего раньше не было

(0) Наверное тут только поиск закономерностей, смотреть  ЖР хотя бы.

из-за таких скачков CPU у rphost начинает расти показатель "Длина очереди процессора", все начинает подтупливать и соответственно apdex падает у всех показателей. При этом проц у sql редко когда превышает 30%. Можно исключить железо и его настройки, т.к. это не менялось несколько месяцев. Полнотекстного поиска нет. Память rphost не отъедает, все в пределах своих среднемесячных показателей

rphosts, в чём дело?

(4) Почему не работает? ;-)

(0)Разбирай на нити и смотри какая балуется. Задача нетривиальна, поймаете админа в помощь.

мб кто-то из программистов обрабатывает большую ТЗ

(7) тут не должно быть. Смотрю на sql, нет запросов, которые бы делали большую выборку данных

(1) регламентные задания на ночь пробовали у базы отключать ?

(0) Извиняюсь, вероятно, за банальный вопрос. Схема питания какая стоит на сервере? Что вообще за процессор?

(9) нельзя отключать, работаем 24/7
(10) максимальная производительность, ЦП Intel(R) Xeon(R) Gold 6254 CPU @ 3.10GHz

(11)[нельзя отключать, работаем 24/7]
подними копию

(11) Если провести ретроспективный анализ? Что менялось за последнее время? Обновления ОС на сервере? Включение нового функционала в конфигурации? Может криптографию начали использовать, а до этого не было. Ну и (7) все таки может быть. Может у ТЗ индексы строят, а ТЗ большая. К СУБД обращения не будет.

(13) вот и не могу понять, что не то. На вскидку не вроде ничего такого не вводили, что могло бы дать такой результат. С тем же ТЗ, мб. оно где-то есть, но программистов много, на словах никто ничего не делал. А как найти почему грузится проц - не понимаю.
Начинаешь смотреть все подряд: долгие запросы, частые запросы, долгие серверные вызовы, блокировки. Но все это как из пушки по воробьям. Да, что-то ускоряешь, работает быстрее, но нужной причины пока не удается найти

(14) копия на текущем релизе платформы, если ошибка воспроизведётся - поиск с полноценным использованием ТЖ и нагрузочным тестированием

А что в консоли администрирования серверов? Там маломальски есть инфа по сеансам, хотя бы определитесь по пользователям

ЖР чистил? Сохрани куда-нить да почисти. Говорят, что при разрастании ЖР гигов эдак до 15 на старых платформах как раз и начинались тормоза rphostов. Я, правда, сам не проверял, до такого не доводил, у меня ЖР максимум 1ГБ были, чистил регулярно. Да и вообще почистить ЖР лишним никогда не будет. (при предварительном сохранении, разумеется, для истории, на "посмотреть").

(17) мимо. От большого ЖР обычно очередь к диску, а не к процу

(18) никогда не вредно периодически чистить ЖР.

(19) Ну достаточно у него 1 раз настроить разделение на час, день, неделя - в зависимости от нагрузки.

(16) 600 +-. Фоновых около 1000, постоянно работающих 30-50. Тут как бы все в норме, я так работаю не первый год, свою базу знаю. Но вот почему иногда (раз в полгода) начинает проц на rphost висеть - не пойму. Начинаешь все подряд оптимизировать - через несколько неделб уходит нагрузка. Потом через несколько месяц опять внезапно появится. Какой-то закономерности не нашел

(17) он только на ошибки и деление по дням. Очистка его не помогает

(21) Полнотекстовый поиск есть?

(22) нет