|
Как отследить кто нагибает сервер 1С | ☑ | ||
---|---|---|---|---|
0
NWsFF
23.05.18
✎
08:26
|
Ситуация происходит в среднем раз в неделю, рпхосты загружают процессор на 100%, винда начинает приостанавливать рпхосты и соедниянения юзеров отваливаются.
Можно ли в консоле сервера 1с , найти сеанс который загружает проц. Там есть куча параметров типа количество вызовов, чтение , запись и тд. После анализа пиковых значений, не удалось найти источник пиковой нагрузки. Платформа 8.3.10.2639 ,под каждую базу создается свой рпхост (может и в этом дело). Баз 12 штук, ЗУП 3.0 БП 3. Я уже фоновые задания разнес по времени чтобы одновременно не запускались. Есть варианты как отловить причину? (Закрывали квартальную отчетность, думал тоже повалится сервак нет, нормально прошло). Средняя нагрузка на проц 8-11% |
|||
32
unregistered
23.05.18
✎
10:14
|
(0) Высокая загрузка CPU на сервере приложений
https://its.1c.ru/db/metod8dev#content:5814:hdoc Значительное потребление памяти процессами кластера на сервере приложений https://its.1c.ru/db/metod8dev#content:5815:hdoc |
|||
33
xXeNoNx
23.05.18
✎
10:17
|
(30) Ну ну.., если это "извращение", то удачи (15) понеизвращаться...
|
|||
34
NWsFF
23.05.18
✎
10:21
|
(32) тоже самое что и в (27) но уже доступно с учетки ИТС, спасибо
Сейчас посмотрел по "Время вызова общее" с утра максимальное значение 104.186 затем 84, 68, 24 (это с утра, примерно 4-5 часов). В принципе узнал вещи которые не знал, попробую проанализировать. |
|||
35
unregistered
23.05.18
✎
10:22
|
(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% |
|||
36
unregistered
23.05.18
✎
10:25
|
+ к (35)
При необходимости в батник следует добавить еще остановку службы сервера хранилища и службу агента ЦКК. Потом не забыть всё это хозяйство запустить. У 1С на ИТС есть соответствующий батничек для старта всех служб. |
|||
37
unregistered
23.05.18
✎
10:27
|
А вообще по сути дела.
Перестаньте маяться ерундой. Настройте технологический журнал и счетчики производительности винды. |
|||
38
drumandbass
23.05.18
✎
10:32
|
Просто посмотри сначала время вызова СУБД у кого максимум.
|
|||
39
NWsFF
23.05.18
✎
10:34
|
(35) Что дадут счетчики производительности винды, покажет что у меня проц на серваке загружен до 100%, я и так это знаю. Мои счетчики производительности в виде юзеров мне сразу сообщают об этом. Дальше то что?
Технологический журнал попробую включить посмотреть, но плохо себе представляю что там смотреть, пару раз всего пользовался когда искал ошибку. А почему не создавать проц. под каждую иб, в этом есть что-то что может привести к проблемам? |
|||
40
xXeNoNx
23.05.18
✎
10:35
|
(39) А юзеры говорят чем проц сервака загружен?
|
|||
41
NWsFF
23.05.18
✎
10:36
|
(38) в (34) писал, это разве большие показатели для отсчета с утра. Да и база которая показывает масимум появилась уже после проблем с производительностью
|
|||
42
xXeNoNx
23.05.18
✎
10:37
|
(37) не нужны они ему, у него свои счетчики - юзеры(35)
|
|||
43
Адинэснег
23.05.18
✎
10:37
|
(0) консоль адвинистриования
|
|||
44
NWsFF
23.05.18
✎
10:37
|
(39) Некоторых из 1с начинает выкидывать, у остальных все тормозит
|
|||
45
ildary
23.05.18
✎
10:37
|
(39) А вообще известно что именно происходит - это пользователи вешают или рег.задания? Бывает, что рег.задания могут зависать с ошибкой и доводить до ошибки транзакции у пользователей.
|
|||
46
Segate
23.05.18
✎
10:38
|
(39) проц на серваке одноядерный? загружены все ядра или одно? Тормоза во всех рпхостах или в одном? Сколько рпхостов? сколько физических ядер на сервере?
|
|||
47
NWsFF
23.05.18
✎
10:38
|
(37) ты прикидываешься? Что тебе даст счетчик винды, покажет что проц в 9,00 загрузка 100% дальше то что?
|
|||
48
xXeNoNx
23.05.18
✎
10:40
|
(47) Послушай что отцы в (29) и в (37) вещают!
|
|||
49
NWsFF
23.05.18
✎
10:40
|
(39) 4 ядра , 8 потоков XEON E3-1230
|
|||
50
xXeNoNx
23.05.18
✎
10:41
|
(49) крутые ядра у тебя..., что говорят юзеры по этому поводу?
|
|||
51
Segate
23.05.18
✎
10:43
|
(49) по поводу загрузки по ядрам расскажи? т.к. один рпхост одновременно работает только с одним физическим ядром.
ЗЫ 12 рпхостов на 12 баз - явный перебор. сделай 3 базы на процесс и количество пользователей увеличивай |
|||
52
NWsFF
23.05.18
✎
10:43
|
(47) Тебе конкретно вопрос я задал, что мне даст счетчик производительности винды? Какую он мне информацию даст которой я сейчас не знаю. Не юли ответь.
(50) Какой ты юморист |
|||
53
Segate
23.05.18
✎
10:45
|
(52) счетчик винды даст как минимум тонкое место. Если грузятся не все ядра, а одно, значит проблема в конкретном рпхосте, а не во всем серваке. Если загрузка проца полная, то даст информацию по очередям например... из которой ты сможешь дернуть ID процессов которые эти очереди создают... Может у тебя проблема в регаменте, который во всех базах разом что-то делает и создает миллионы контекстных переключений...(что конечно врядли)
|
|||
54
H A D G E H O G s
23.05.18
✎
10:46
|
(51) Вы несете дичь.
|
|||
55
Segate
23.05.18
✎
10:46
|
(54) в чем я не прав? )
|
|||
56
H A D G E H O G s
23.05.18
✎
10:47
|
(55) В том, что rphost работает только с 1 ядром.
|
|||
57
xXeNoNx
23.05.18
✎
10:48
|
(52)->(47)
(42)->(39) Зачем сам с собой общаешься? Не только юморист, еще и крестиком вышиваю. По теме: по дефолту кластер, настроить ТЖ и счетчики, почитать статьи в (32). счетчики нужны для того что бы были, они используются для расследования проблем производительности. |
|||
58
Вафель
23.05.18
✎
10:48
|
(56) ты имел ввиду 1 поток рпхоста работает с 1 ядром?
|
|||
59
sknhb
23.05.18
✎
10:48
|
(56) бред
|
|||
60
H A D G E H O G s
23.05.18
✎
10:48
|
(58) Конечно. Поток, а не процесс.
|
|||
61
xXeNoNx
23.05.18
✎
10:48
|
+(57) но счетчики можно заменить юзерами, которые помогут в расследовании
|
|||
62
sknhb
23.05.18
✎
10:49
|
упс, (59) к (51)
|
|||
63
NWsFF
23.05.18
✎
10:52
|
(61) "Счетчики нужны чтобы они были" "юзеры, юзеры" прилип как гавно, отлипни.
|
|||
64
H A D G E H O G s
23.05.18
✎
10:55
|
||||
65
xXeNoNx
23.05.18
✎
10:56
|
(63) Нет уж.., я еще не закончил, я помогу тебе вылечить сервер 1с
|
|||
66
H A D G E H O G s
23.05.18
✎
10:57
|
Но я чет, сомневаюсь, что проблема в коде, а не в косяке данных/кэше/оборудовании.
Процессы приостанавливаются на виндой, а менеджером сервера, когда с процессом rphost что-то не так. |
|||
67
Segate
23.05.18
✎
10:58
|
(56) В 8.3 до сих пор не реализован нормальный паралеллизм. Так что по факту - количество рп больше чем ядер не нужно.
если это не так - расскажи почему? Насколько я понимаю, перераспределение задач по ядрам происходит в случае необходимости при помощи нума, Если это не так - то поправьте меня. |
|||
68
H A D G E H O G s
23.05.18
✎
11:01
|
(67) У вас винегрет в голове.
Вы путаете Numa и многоядерность. Проблемы с NUMA (когда у тебя в системе несколько отдельных процессоров) - действительно есть. https://its.1c.ru/db/metod8dev#content:5903:hdoc:_top:numa С многоядерностью - нет. Запустите в 3 сеансах такой код на сервере Пока ИСТИНА ЦИКЛ КонецЦикла; и посмотрите загрузку. |
|||
69
Вафель
23.05.18
✎
11:02
|
случайно не виртуалка?
|
|||
71
Segate
23.05.18
✎
11:05
|
(68) я предположу(т.к. нет идеального тестового стенда под рукой) что загрузка должна распределиться на 3 ядра. при этом производительность одного из сеансов должна быть выше чем 2 других. поправьте, если я не прав.
|
|||
72
NWsFF
23.05.18
✎
11:05
|
Подведем итоги, что я сделаю
1. Включу счетчики производительности видны. 2. Включу ТЖ и проведу анализ как(64) 3. Поставлю 3 ИБ на процесс 4. Проведу анализ как в (32) (69) не виртуалка , не рдп, все по классике в единой локальной сети |
|||
73
Segate
23.05.18
✎
11:06
|
(72) не 3 иб на процесс, это я налажал конечно... это сработает если в иб одинаковое количество юзеров.
посчитайте по формуле из (68) |
|||
74
H A D G E H O G s
23.05.18
✎
11:07
|
(72) Счетчики производительности Венды тебе могут помочь только, если ты можешь воспроизвести 100 нагрузку. Сам.
Пишешь трек, видишь - пошла загрузка, в конфигураторе стопишь выполнение, и смотришь, где ты в коде. |
|||
75
xXeNoNx
23.05.18
✎
11:08
|
(72) а почему не сослался в п.1 на (29)?
|
|||
76
NWsFF
23.05.18
✎
11:10
|
(75) Ты задрал,и так всем понятно что этот пункт я только ради тебя включил. Хотел даже дописать про это, но не стал выеживаться...
|
|||
77
MaxS
23.05.18
✎
11:12
|
Кто? Вините во всём Обаму. Он немного освободился от дел и вплотную занялся процессами на 1с сервере.
Или регламентные задания баз 1С посмотреть. Временно поотключать почти всё. |
|||
78
xXeNoNx
23.05.18
✎
11:13
|
(76) вот..., это уже нормальный подход..., продолжаем
|
|||
79
ildary
23.05.18
✎
12:26
|
Задам попутный вопрос - а если на компьютере два жестких диска, на одном - база 1С, на другом - например архивы. Если средняя очередь второго диска вдруг стала больше 1 - будет ли тормозиться работа 1С?
|
|||
80
xXeNoNx
23.05.18
✎
12:48
|
(79) будет, потому что у него будет большая нагрузка на проц
|
|||
81
ildary
23.05.18
✎
12:51
|
(80) Я правильно поянял - процессор ждет освобождения очереди диска и поэтому подтормаживает другие задачи?
|
|||
82
H A D G E H O G s
23.05.18
✎
12:57
|
(81) Ты правильно понял неправильный ответ в (80). :-)
Нагрузка на проц будет маленькая, проц будет ждать, пока обмен с диском не закончится. |
|||
83
NWsFF
23.05.18
✎
13:03
|
Включил ТЖ как в (64).
За 2 часа пол гига логов нахерачил. Самый продолжительный вызов 29 секунд (суммарный) (ОбщаяФорма.ПечатьДокумента), ничего подозрительного, но сервер второй раз в нокаут ушел. |
|||
84
ildary
23.05.18
✎
13:06
|
(82) я именно это и написал, только другими словами.
Получается, что на сервере 1С нельзя днем делать любые операции, которые могут вызвать рост очереди диска, даже если это вторичный диск. |
|||
85
Вафель
23.05.18
✎
13:10
|
может фоновое какое? кстати ЖР в каком формате?
|
|||
86
H A D G E H O G s
23.05.18
✎
13:14
|
Да, точно.
Когда ЖР в mysql формате уходит за 8 Гиг - менеджер начинает почти непрерывно писать в файл ЖР. |
|||
87
Вафель
23.05.18
✎
13:15
|
(86) если бы он был в mysql - то все бы было зашибись
|
|||
88
H A D G E H O G s
23.05.18
✎
13:17
|
(87) не понял. Он и так в mysql
|
|||
89
Вафель
23.05.18
✎
13:17
|
(88) sqlite
|
|||
90
H A D G E H O G s
23.05.18
✎
13:18
|
(89) Блин, точно.
|
|||
91
H A D G E H O G s
23.05.18
✎
13:18
|
Развелось sql-лев.
|
|||
92
xXeNoNx
23.05.18
✎
14:02
|
(82) нет правильный, "Задам попутный вопрос - а если на компьютере два жестких диска, на одном - база 1С, на другом - например архивы. Если средняя очередь второго диска вдруг стала больше 1 - будет ли тормозиться работа 1С?"
Аналогично будет ли моя машина ехать, если я в нее залью 95 бензин. Ответ - нет, не будет, потому что у нее нет колес. Что за постановка вопроса в (79)? |
|||
93
ildary
23.05.18
✎
14:03
|
(86) на сегодня других вариантов, кроме как переводить на старый формат - нет?
|
|||
94
NWsFF
23.05.18
✎
14:03
|
ЖР в SQLlite, во всех базах включена полная регистрация.
(86) Нашел 3 базы LGD 31,15,27 ГБ %(, щас будем урезать |
|||
95
H A D G E H O G s
23.05.18
✎
14:05
|
(93) Нет
|
|||
96
xXeNoNx
23.05.18
✎
14:11
|
(83) ограничения сделай, я бы сначала собирал лог с событием EXCP, а именно:
Отключил ТЖ, почистил ТЖ, перезапустил рпхосты, включил ТЖ, подождал роста загруженности проца рпхостами(я так понял что это они проц грузят), срубил бы эти рпхосты снова, событие EXCP должно упасть в ТЖ вот и смотри что именно ты срубил по контексту, если он есть. |
|||
97
xXeNoNx
23.05.18
✎
14:19
|
вот по такой ТЖ это покажет и относительно не будет роста логов..., наверное:
<?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> |
|||
98
xXeNoNx
23.05.18
✎
14:19
|
+(97) Пути поменяй тока
|
|||
99
NWsFF
23.05.18
✎
14:27
|
(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> |
|||
100
xXeNoNx
23.05.18
✎
14:27
|
(15) у нормальных пацанов ТЖ работает всегда
|
|||
101
xXeNoNx
23.05.18
✎
14:30
|
(99) Событие CALL - не покажет проблемы, наоборот, может служить проблемой сбор таких данных, потому их очень много будет сыпаться в ТЖ
|
|||
102
xXeNoNx
23.05.18
✎
14:30
|
||||
103
xXeNoNx
23.05.18
✎
14:31
|
нужны события EXCP и EXCPCNTX
|
|||
104
ildary
23.05.18
✎
15:07
|
(100) зачем включать ТЖ, если нет ошибок? Он ведь будет тормозить систему и жрать место на диске.
|
|||
105
Lama12
23.05.18
✎
15:22
|
(100) Эх... Это если аппаратура позволяет.
(104) Только за счет этого выяснили кто и как последовательность сбивают на 17 год от Р.Х. Оказалось в УПП, в обработке восстановление последовательности можно спокойно поставить 17 год, и нажать кнопку восстановить. Даже при закрытом периоде, сначала сбивается последовательность, а потом отрабатывает закрытый период. Естественно последовательность обратно не возвращается. |
|||
106
xXeNoNx
23.05.18
✎
15:28
|
(104) какие Ваши доказательства?
|
|||
107
xXeNoNx
23.05.18
✎
15:31
|
(104) Они есть, но о них многие не догадываются
|
|||
108
Feanor
23.05.18
✎
16:45
|
(101) по событиям CALL можно посчитать суммарное время серверных вызовов и найти контекст самых длительных
|
|||
109
Feanor
23.05.18
✎
16:45
|
(103) чем EXCP поможет при расследовании высокой нагрузки на ЦП?
|
|||
110
xXeNoNx
23.05.18
✎
17:30
|
(109) когда пользователей срубит, контекст упадет в excp или не упадет.
|
|||
111
Feanor
23.05.18
✎
17:51
|
(110) очень маловероятно, что это будет сессия виновника высокой нагрузки
|
|||
112
xXeNoNx
23.05.18
✎
17:53
|
(111) предлагаю перечитать предыдущие сообщения
|
|||
113
Feanor
23.05.18
✎
17:56
|
(112) какие именно?
|
|||
114
xXeNoNx
23.05.18
✎
18:52
|
(113) все сообщения, все....
|
|||
115
xXeNoNx
23.05.18
✎
18:58
|
(108) чио нам дадут длительные вызовы, ну длительные они, да и фиг бы с ними...
|
|||
116
xXeNoNx
23.05.18
✎
19:07
|
(0) что дали счетчики? Какие счетчики настроил?
|
|||
117
Feanor
23.05.18
✎
20:53
|
(115) длительные вызовы нагружают проц, ваш КЭП )
|
|||
118
Cyberhawk
23.05.18
✎
21:00
|
(117) С какого?
|
|||
119
xXeNoNx
23.05.18
✎
21:01
|
(117) или не нагружают...
|
|||
120
FormatC
23.05.18
✎
21:01
|
(0) может быть кто-то просмотреть большой журнал регистрации с отбором... как-то раз сталкивался с таким.
|
|||
121
xXeNoNx
23.05.18
✎
21:03
|
(120) вполне может быть.., грохнуть журнал и посмотреть
|
|||
122
Feanor
23.05.18
✎
21:18
|
(118) если выполняется серверный вызов, то это в 99,99% случаев либо исполнение кода на встроенном языке (рпхост грузит проц), либо выполнение запроса к СУБД. Есть еще что-то?
|
|||
123
Cyberhawk
24.05.18
✎
01:25
|
(122) Не понял, к чему ты клонишь. Так все время исполнения кода на сверере можно свести к выполнению кода или ожиданию результата запроса
|
|||
124
cons74
24.05.18
✎
08:56
|
Какие новости?
|
|||
125
Feanor
24.05.18
✎
09:46
|
(123) очевидно же, что у чела "рпхосты загружают процессор на 100%", нужно расследовать эту проблему. Есть какие-то другие способы ее расследовать?)
|
|||
126
Cyberhawk
24.05.18
✎
09:47
|
(125) Так это всплеск вроде, вызванный их массовым одновременным перезапуском. Длительность вызовов - следствие.
|
|||
127
Feanor
24.05.18
✎
10:09
|
(126) ну это бабка надвое сказала, было лишь предположение, которое ничем не обосновано
|
|||
128
Cyberhawk
24.05.18
✎
11:00
|
(127) Ну долгие вызовы / запросы, может, и нужно про анализировать, но т.к. характер "точечный" (редкий всплеск), то ты в результате даже если и узнаешь эти "длительные операции", то что это даст? По пятницаам этот запрос / код долгий, а по остальным дням недели - нет. Значит дело не в этом )
|
|||
129
Cyberhawk
24.05.18
✎
11:00
|
*проанализировать
|
|||
130
Feanor
24.05.18
✎
11:09
|
(128) могут и рабочие процессы падать и перезапускаться, а может и какая-то регламентная операция запускаться в определенное время и грузить систему. Нужно копать)
|
|||
131
Cyberhawk
24.05.18
✎
11:58
|
(130) Мне казалось, что ТС первым делом должен был сопоставить время всплесков с расписанием РЗ )
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |