Имя: Пароль:
1C
1С v8
Как отследить кто нагибает сервер 1С
, ,
0 NWsFF
 
23.05.18
08:26
Ситуация происходит в среднем раз в неделю, рпхосты загружают процессор на 100%, винда начинает приостанавливать рпхосты и соедниянения юзеров отваливаются.
Можно ли в консоле сервера 1с , найти сеанс который загружает проц. Там есть куча параметров типа количество вызовов, чтение , запись и тд. После анализа пиковых значений, не удалось найти источник пиковой нагрузки.
Платформа 8.3.10.2639 ,под каждую базу создается свой рпхост (может и в этом дело). Баз 12 штук, ЗУП 3.0 БП 3. Я уже фоновые задания разнес по времени чтобы одновременно не запускались.
Есть варианты как отловить причину? (Закрывали квартальную отчетность, думал тоже повалится сервак нет, нормально прошло).
Средняя нагрузка на проц 8-11%
1 NWsFF
 
23.05.18
08:37
Базы типовые
2 cons74
 
23.05.18
08:40
"под каждую базу создается свой рпхост (может и в этом дело)" - не в этом.
Если действительно все рпхосты разом загружают процессор на 100% то похоже на перезапуск всех процессов разом. По истечению времени жизни. Выложи картику: http://dropmefiles.com/iG9Ug
3 NWsFF
 
23.05.18
08:58
(2) Там стоит 0, процессы не перзапускаются, вообще на этой форме все по нулям и приоритет на производительности
4 NWsFF
 
23.05.18
08:59
сервер перегружается каждую ночь
5 ildary
 
23.05.18
08:59
(3) а может стОит перезапускать процессы раз в сутки/неделю?
6 ildary
 
23.05.18
09:01
(4) Не успел увидеть вопрос снят. Но мне когда-то админы утверждали, что частый ребут сервера - вреден. Даже раз в неделю не хотели делать.
7 cons74
 
23.05.18
09:03
(3) тогда другой вариант: кто-то запускает дикий жесткий внешний отчет (или встроенный отчет, но без отборов - за все года по всем аналитикам), который сжирает всю память в ноль.
8 NWsFF
 
23.05.18
09:09
(7) памяти 32 гига , 18 на SQL отдано, остальное рпхостам, в момент пиковой нагрузки было доступно еще 4 гига, проблем в нехватке памяти нет.

А по поводу перегрузки сервера каждый день, это было сделано для разгона юзеров, но не работало, после перегрузки сеансы снова восстанавливались, может еще здесь как то собака порылась. И остановка службы 1с батниками и запуск через час тоже не помогали. Я так и не понял почему такое происходит.
9 piter3
 
23.05.18
09:15
(8) если rdp то не настроен выход из сеанса по бездействию
10 cons74
 
23.05.18
09:16
(8) тогда в момент Х смотрите в консоли сервера 1с сеансы, сортируя поочередно по колонкам.
11 cons74
 
23.05.18
09:17
и что там с внешними отчетами?
12 NWsFF
 
23.05.18
09:18
(10) Вот сейчас смотрю, бух записьвсего 1236794654 , спрашиваю что делала, говорит только платежки набивала.. и по памяти она рекордсмен 1989947775.
Врать не станет
13 NWsFF
 
23.05.18
09:22
ну это я уже смотрю сейчас всего (сеанс начать 3 часа назад), попробую в момент загрузки смотреть текущие значения, но уже смотрел не смог отловить кто и что причина.
14 Serg_1960
 
23.05.18
09:23
"после перегрузки сеансы снова восстанавливались" - еслиуж перегружать, то перезагружать оба сервера (1С и SQL) Сервер SQL "восстанавливает" прерванные соединения. Имхо. У Вас действительно проблемы... не только с железом :)
15 Lama12
 
23.05.18
09:23
Наверно извращение, но может включить технологический журнал?
16 Serg_1960
 
23.05.18
09:24
Хотелось бы уточнения: rphost или rphostЫ, 8.2 или 8.3?
17 lodger
 
23.05.18
09:30
(13) динамосписок в платежках?
18 NWsFF
 
23.05.18
09:32
(16) 8.3
(14) 1с и скл живут на одном сервере

И еще момент восстанавливали сеансы базы с толстыми клиентами, и сами базы в режиме совместимости с 8.2 8.1. Но это так отступление от темы, потому что это происходит и на другом сервере где проблем с пиковыми нагрузками нет.

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

13. Стандартные платежки БП3
19 Serg_1960
 
23.05.18
09:35
(18) Да, спс, я знаю - у Вас платформа 8.3.10.2639. У меня 8.3.11.3034 и сейчас сидят два десятка пользователей на одном(!) rphost-е сервера 1С - ЧЯДНТ?
20 NWsFF
 
23.05.18
09:35
Ну возможно просто проц. слабый, сервер такой себе в плане процессора. В среднем порядка 70 сеансов, проц XEON E3-1230 3.3 ГГЦ
Но блин иногда неделями же работает без проблем, и пиковая нагрузка проходит в течении 10-30 минут
21 Serg_1960
 
23.05.18
09:39
(офф) Имхо, в 1С сложно угадать что не так пошло. Помню, было дело, поймал ошибку платформы, когда всю память сервер активно забивал в то время, когда в базе работали только рег.задания без активных пользователей...
22 Никулин Леонид
 
23.05.18
09:41
в консоли администрирования смотри колонку "Захвачено СУБД"
23 sknhb
 
23.05.18
09:46
24 NWsFF
 
23.05.18
09:52
(22) Там вообще по нулям, эта колонка мне знакома когда переводил с бп2 - бп3 там висели большие значения и сам перевод висел но сервер работал как надо...
25 NWsFF
 
23.05.18
09:54
(23) Статья для избранных ни с учетки ИТС, не с учетки с доступом к конференции 1с не пустило.
26 Serg_1960
 
23.05.18
09:55
Если у автора действительно rphostЫ, то по Диспетчеру задач на закладка "Подробности" можно подсмотреть идентификатор процесса, который грузит сервер, а в оснастке администрирования серверов 1С, в сеансах, можно посмотреть кто сидит на этом процессе, чем занят - журнал регистрации. Круг ссужается. Как вариант, имхо, интерес также вызывают те пользователи, которые грузят сервер,  но в журнале регистрации действий не имеют записей в этот период - не исключено что они грузят сервер отчетами.
27 sknhb
 
23.05.18
09:56
(25) Что требуется сделать

Подключиться к указанному серверу
Запускаем Process Explorer
Находим процесс-виновника
Если виновник - rphost
Заходим в консоль администрирования кластера серверов
Находим сеансы, находящиеся в длительном клиент-серверном вызове (колонка "Время вызова (текущее)") и не в вызове СУБД (колонка "Время вызова СУБД (текущее)")
Записываем их номера и время начала сеансов, записываем их базы
Завершаем сеансы
Убеждаемся, что нагрузка упала
Расследуем по журналу регистрации, какой именно сценарий отрабатывали завершенные сеансы (Что именно они делали?)
Если виновник rmngr
Находим сеансы, находящиеся в длительном клиент-серверном вызове (колонка "Время вызова (текущее)") и не в вызове СУБД (колонка "Время вызова СУБД (текущее)")
Записываем их номера и время начала сеансов, записываем их базы
По журналу регистрации пробуем понять, что делают сеансы.
Если виновник не понятен, то снимаем дамп с помощью утилиты ProcDump http://technet.microsoft.com/en-us/sysinternals/dd996900.asp
Полученные дампы и технологические журналы (если собирались) отправляем в 1С с подробным описанием проблемы и симптомов
28 ptiz
 
23.05.18
09:59
(0) Всё-таки попробовать обновить платформу, хотя бы на последнюю 8.3.10. А вдруг поможет.
29 xXeNoNx
 
23.05.18
10:01
ПОСТ № 29 - Виндовые счетчики и ТЖ не предлагали?
30 Serg_1960
 
23.05.18
10:05
(29) Предлагали в (15) в качестве извращения :)
31 NWsFF
 
23.05.18
10:13
(27) Спасибо, буду пробовать.
Но вешает базу не один рпхост, нагрузка немного размазана по 2-3 процессам.
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) Мне казалось, что ТС первым делом должен был сопоставить время всплесков с расписанием РЗ )
Глупец, лишенный способности посмеяться над собой вместе с другими, не сможет долго выносить программирование. Фредерик Брукс-младший