Имя: Пароль:
1C
1С v8
Как отследить кто нагибает сервер 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) Мне казалось, что ТС первым делом должен был сопоставить время всплесков с расписанием РЗ )