Ситуация происходит в среднем раз в неделю, рпхосты загружают процессор на 100%, винда начинает приостанавливать рпхосты и соедниянения юзеров отваливаются.
Можно ли в консоле сервера 1с , найти сеанс который загружает проц. Там есть куча параметров типа количество вызовов, чтение , запись и тд. После анализа пиковых значений, не удалось найти источник пиковой нагрузки.
Платформа 8.3.10.2639 ,под каждую базу создается свой рпхост (может и в этом дело). Баз 12 штук, ЗУП 3.0 БП 3. Я уже фоновые задания разнес по времени чтобы одновременно не запускались.
Есть варианты как отловить причину? (Закрывали квартальную отчетность, думал тоже повалится сервак нет, нормально прошло).
Средняя нагрузка на проц 8-11%

(0) Высокая загрузка CPU на сервере приложений
https://its.1c.ru/db/metod8dev#content:5814:hdoc

Значительное потребление памяти процессами кластера на сервере приложений
https://its.1c.ru/db/metod8dev#content:5815:hdoc

(30) Ну ну.., если это "извращение", то удачи (15) понеизвращаться...

(32) тоже самое что и в (27) но уже доступно с учетки ИТС, спасибо
Сейчас посмотрел по "Время вызова общее" с утра максимальное значение 104.186 затем  84, 68, 24 (это с утра, примерно 4-5 часов).
В принципе узнал вещи которые не знал, попробую проанализировать.

(0) > под каждую базу создается свой рпхост

Зачем?
Этой фигнёй имеет смысл страдать в исключительных случаях в целях расследования проблем. Например, когда никак не удаётся вычислить, какая именно ИБ сбоит.

(4) > сервер перегружается каждую ночь

Зачем? Вам больше заняться нечем?

(8) > это было сделано для разгона юзеров

Зачем? Чем вам мешают работающие юзеры?

> остановка службы 1с батниками и запуск через час тоже не помогали

Это от того, что кому-то лень почитать документацию. Пример "правильного" батника от 1С (для 64-битного сервера, у которого папка кластера размещена по нетиповому пути "F:\srvinfo\reg_1541", а пользователь, от имени которого работает служба 1С называется Admin_1C):

set LOG_FILE="scripts.log"
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-
64)"
set SERVICE_RAS_NAME="1C:Enterprise 8.3 Remote Server"
set CNTX_PATH="F:\srvinfo\reg_1541"
set PFL_PATH="C:\ProgramData\1C\1cv8"
set TEMP_PATH="C:\Windows\Temp"
set TEMP_1C_PATH="C:\Users\Admin_1C\AppData\Local\Temp"
echo stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
sc stop %SERVICE_1C_NAME%
sc stop %SERVICE_RAS_NAME%
timeout 5
taskkill /f /im "rphost.exe"
taskkill /f /im "rmngr.exe"
taskkill /f /im "ragent.exe"
taskkill /f /im "ras.exe"
timeout 5
echo done stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
echo clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
DEL /Q /F /S %CNTX_PATH%\snccntx*
DEL /Q /F %PFL_PATH%\*.pfl
DEL /Q /F /S %TEMP_PATH%\*.*
DEL /Q /F /S %TEMP_1C_PATH%\*.*
echo done clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%

+ к (35)
При необходимости в батник следует добавить еще остановку службы сервера хранилища и службу агента ЦКК.

Потом не забыть всё это хозяйство запустить. У 1С на ИТС есть соответствующий батничек для старта всех служб.

А вообще по сути дела.
Перестаньте маяться ерундой.
Настройте технологический журнал и счетчики производительности винды.

Просто посмотри сначала время вызова СУБД у кого максимум.

(35) Что дадут счетчики производительности винды, покажет что у меня проц на серваке загружен до 100%, я и так это знаю. Мои счетчики производительности в виде юзеров мне сразу сообщают об этом. Дальше то что?
Технологический журнал попробую включить посмотреть, но плохо себе представляю что там смотреть, пару раз всего пользовался когда искал ошибку.

А почему не создавать проц. под каждую иб, в этом есть что-то что может привести к проблемам?

(39) А юзеры говорят чем проц сервака загружен?

(38) в (34) писал, это разве большие показатели для отсчета с утра. Да и база которая показывает масимум появилась уже после проблем с производительностью

(37) не нужны они ему, у него свои счетчики - юзеры(35)

(0) консоль адвинистриования

(39) Некоторых из 1с начинает выкидывать, у остальных все тормозит

(39) А вообще известно что именно происходит - это пользователи вешают или рег.задания? Бывает, что рег.задания могут зависать с ошибкой и доводить до ошибки транзакции у пользователей.

(39) проц на серваке одноядерный? загружены все ядра или одно? Тормоза во всех рпхостах или в одном? Сколько рпхостов? сколько физических ядер на сервере?

(37) ты прикидываешься? Что тебе даст счетчик винды, покажет что проц в 9,00 загрузка 100% дальше то что?

(47) Послушай что отцы в (29) и в (37) вещают!

(39) 4 ядра , 8 потоков XEON E3-1230

(49) крутые ядра у тебя..., что говорят юзеры по этому поводу?

(49) по поводу загрузки по ядрам расскажи? т.к. один рпхост одновременно работает только с одним физическим ядром.

ЗЫ 12 рпхостов на 12 баз - явный перебор. сделай 3 базы на процесс и количество пользователей увеличивай

(47) Тебе конкретно вопрос я задал, что мне даст счетчик производительности винды? Какую он мне информацию даст которой я сейчас не знаю. Не юли ответь.
(50) Какой ты юморист

(52) счетчик винды даст как минимум тонкое место. Если грузятся не все ядра, а одно, значит проблема в конкретном рпхосте, а не во всем серваке. Если загрузка проца полная, то даст информацию по очередям например... из которой ты сможешь дернуть ID процессов которые эти очереди создают... Может у тебя проблема в регаменте, который во всех базах разом что-то делает и создает миллионы контекстных переключений...(что конечно врядли)

(51) Вы несете дичь.

(54) в чем я не прав? )

(55) В том, что rphost работает только с 1 ядром.

(52)->(47)
(42)->(39)
Зачем сам с собой общаешься?
Не только юморист, еще и крестиком вышиваю.

По теме: по дефолту кластер, настроить ТЖ и счетчики, почитать статьи в (32).
счетчики нужны для того что бы были, они используются для расследования проблем производительности.

(56) ты имел ввиду 1 поток рпхоста работает с 1 ядром?

(56) бред

(58) Конечно. Поток, а не процесс.

+(57) но счетчики можно заменить юзерами, которые помогут в расследовании

упс, (59) к (51)

(61) "Счетчики нужны чтобы они были" "юзеры, юзеры" прилип как гавно, отлипни.

https://its.1c.ru/db/metod8dev#content:5906:hdoc

(63) Нет уж.., я еще не закончил, я помогу тебе вылечить сервер 1с

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

Процессы приостанавливаются на виндой, а менеджером сервера, когда с процессом rphost что-то не так.

(56) В 8.3 до сих пор не реализован нормальный паралеллизм. Так что по факту - количество рп больше чем ядер не нужно.
если это не так - расскажи почему?
Насколько я понимаю, перераспределение задач по ядрам происходит в случае необходимости при помощи нума, Если это не так - то поправьте меня.

(67) У вас винегрет в голове.

Вы путаете Numa и многоядерность.

Проблемы с NUMA (когда у тебя в системе несколько отдельных процессоров) - действительно есть.
https://its.1c.ru/db/metod8dev#content:5903:hdoc:_top:numa

С многоядерностью - нет.

Запустите в 3 сеансах такой код на сервере

Пока ИСТИНА ЦИКЛ КонецЦикла;

и посмотрите загрузку.

случайно не виртуалка?

(68) я предположу(т.к. нет идеального тестового стенда под рукой) что загрузка должна распределиться на 3 ядра. при этом производительность одного из сеансов должна быть выше чем 2 других. поправьте, если я не прав.

Подведем итоги, что я сделаю
1. Включу счетчики производительности видны.
2. Включу ТЖ и проведу анализ как(64)
3. Поставлю 3 ИБ на процесс
4. Проведу анализ как в (32)

(69) не виртуалка , не рдп, все по классике в единой локальной сети

(72) не 3 иб на процесс, это я налажал конечно... это сработает если в иб одинаковое количество юзеров.

посчитайте по формуле из (68)

(72) Счетчики производительности Венды тебе могут помочь только, если ты можешь воспроизвести 100 нагрузку. Сам.
Пишешь трек, видишь - пошла загрузка, в конфигураторе стопишь выполнение, и смотришь, где ты в коде.

(72) а почему не сослался в п.1 на (29)?

(75) Ты задрал,и так всем понятно что этот пункт я только ради тебя включил. Хотел даже дописать про это, но не стал выеживаться...

Кто? Вините во всём Обаму. Он немного освободился от дел и вплотную занялся процессами на 1с сервере.

Или регламентные задания баз 1С посмотреть. Временно поотключать почти всё.

(76) вот..., это уже нормальный подход..., продолжаем

Задам попутный вопрос - а если на компьютере два жестких диска, на одном - база 1С, на другом - например архивы. Если средняя очередь второго диска вдруг стала больше 1 - будет ли тормозиться работа 1С?

(79) будет, потому что у него будет большая нагрузка на проц

(80) Я правильно поянял - процессор ждет освобождения очереди диска и поэтому подтормаживает другие задачи?

(81) Ты правильно понял неправильный ответ в (80). :-)

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

Включил ТЖ как в (64).
За 2 часа пол гига логов нахерачил. Самый продолжительный вызов 29 секунд (суммарный) (ОбщаяФорма.ПечатьДокумента), ничего подозрительного, но сервер второй раз в нокаут ушел.

(82) я именно это и написал, только другими словами.

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

может фоновое какое? кстати ЖР в каком формате?

Да, точно.
Когда ЖР в mysql формате уходит за 8 Гиг - менеджер начинает почти непрерывно писать в файл ЖР.

(86) если бы он был в mysql - то все бы было зашибись

(87) не понял. Он и так в mysql

(88) sqlite

(89) Блин, точно.

Развелось sql-лев.

(82) нет правильный, "Задам попутный вопрос - а если на компьютере два жестких диска, на одном - база 1С, на другом - например архивы. Если средняя очередь второго диска вдруг стала больше 1 - будет ли тормозиться работа 1С?"

Аналогично будет ли моя машина ехать, если я в нее залью 95 бензин. Ответ - нет, не будет, потому что у нее нет колес.

Что за постановка вопроса в (79)?

(86) на сегодня других вариантов, кроме как переводить на старый формат - нет?

ЖР в SQLlite, во всех базах включена полная регистрация.
(86) Нашел 3 базы LGD 31,15,27 ГБ %(, щас будем урезать

(93) Нет

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

вот по такой ТЖ это покажет и относительно не будет роста логов..., наверное:

<?xml version="1.0"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">;
    <dump create="true" location="C:\Logs\dumps" type="3" prntscrn="true"/>
    <log location="C:\Logs\logcfg" history="28">
        <event>
            <eq property="Name" value="EXCP"/>
        </event>
        <event>
            <eq property="Name" value="EXCPCNTX"/>
        </event>
        <event>
            <eq property="Name" value="CONN"/>
        </event>
        <event>
            <eq property="Name" value="PROC"/>
        </event>
        <event>
            <eq property="Name" value="ADMIN"/>
        </event>
        <event>
            <eq property="Name" value="SESN"/>
        </event>
        <event>
            <eq property="Name" value="CLSTR"/>
        </event>
        <event>
            <eq property="Name" value="LEAKS"/>
        </event>
        <event>
            <eq property="Name" value="QERR"/>
        </event>
        <event>
            <eq property="Name" value="SDBL"/>
            <ge property="Durationus" value="10000000"/>
        </event>
        <event>
            <ne property="Name" value=""/>
            <ge property="Durationus" value="15000000"/>
        </event>
        <property name="all"/>
    </log>
</config>

+(97) Пути поменяй тока

(98)
у меня был, из (64)
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">;
<log location="C:\LOGS\CALL" history="12">
<event>
<eq property="Name" value="CALL"/>
</event>
<property name="all"/>
</log>  
</config>

(15) у нормальных пацанов ТЖ работает всегда

(99) Событие CALL - не покажет проблемы, наоборот, может служить проблемой сбор таких данных, потому их очень много будет сыпаться в ТЖ

https://курсы-по-1с.рф/articles/технологический-журнал-события/

нужны события EXCP и EXCPCNTX

(100) зачем включать ТЖ, если нет ошибок? Он ведь будет тормозить систему и жрать место на диске.

(100) Эх... Это если аппаратура позволяет.
(104) Только за счет этого выяснили кто и как последовательность сбивают на 17 год от Р.Х. Оказалось в УПП, в обработке восстановление последовательности можно спокойно поставить 17 год, и нажать кнопку восстановить. Даже при закрытом периоде, сначала сбивается последовательность, а потом отрабатывает закрытый период. Естественно последовательность обратно не возвращается.

(104) какие Ваши доказательства?

(104) Они есть, но о них многие не догадываются

(101) по событиям CALL можно посчитать суммарное время серверных вызовов и найти контекст самых длительных

(103) чем EXCP поможет при расследовании высокой нагрузки на ЦП?

(109) когда пользователей срубит, контекст упадет в excp или не упадет.

(110) очень маловероятно, что это будет сессия виновника высокой нагрузки

(111) предлагаю перечитать предыдущие сообщения

(112) какие именно?

(113) все сообщения, все....

(108) чио нам дадут длительные вызовы, ну длительные они, да и фиг бы с ними...

(0) что дали счетчики? Какие счетчики настроил?

(115) длительные вызовы нагружают проц, ваш КЭП )

(117) С какого?

(117) или не нагружают...

(0) может быть кто-то просмотреть большой журнал регистрации с отбором... как-то раз сталкивался с таким.

(120) вполне может быть.., грохнуть журнал и посмотреть

(118) если выполняется серверный вызов, то это в 99,99% случаев либо исполнение кода на встроенном языке (рпхост грузит проц), либо выполнение запроса к СУБД. Есть еще что-то?

(122) Не понял, к чему ты клонишь. Так все время исполнения кода на сверере можно свести к выполнению кода или ожиданию результата запроса

Какие новости?

(123) очевидно же, что у чела "рпхосты загружают процессор на 100%", нужно расследовать эту проблему. Есть какие-то другие способы ее расследовать?)

(125) Так это всплеск вроде, вызванный их массовым одновременным перезапуском. Длительность вызовов - следствие.

(126) ну это бабка надвое сказала, было лишь предположение, которое ничем не обосновано

(127) Ну долгие вызовы / запросы, может, и нужно про анализировать, но т.к. характер "точечный" (редкий всплеск), то ты в результате даже если и узнаешь эти "длительные операции", то что это даст? По пятницаам этот запрос / код долгий, а по остальным дням недели - нет. Значит дело не в этом )

*проанализировать

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

(130) Мне казалось, что ТС первым делом должен был сопоставить время всплесков с расписанием РЗ )