Мониторинг работы

[Logger]

Цитата:

Сообщение от glibs

Хм...

Желающие могут ознакомиться в приложении.

С удовольствием послушаю критику.

Здорово.
Риспект.

глянул в код - непонятно, зачем делать 100 сессий. Если 100 пользователей сидит - получится 10 тыс. записей в таблице.

Да и аос будет нагружать, что исказит картину.
Может сделать 1-2 считывания через некоторый промежуток времени.

Например поставит 2 цикла а не 100 и в теле цикла поставить sleep(1000)

[glibs]

Я уже не помню, почему так сделал .

Наверное, разгадка вот в этом.

Цитата:

Сообщение от glibs

...
что-то аналигичное журналу PerfMon'а. Я по такому принципу делал.
...

По-моему, я как раз в то время баловался с этой цацкой, и мне понравилось.

Я пока не пользовался этим, так что в каком его направлении лучше развивать пока не думал.

[kBace4ka]

Было бы неплохо добавить отображение блокировок Оркала.
Что бы видеть какой пользователь блокирует работу остальных.

[mazzy]

Цитата:

Сообщение от kBace4ka

Было бы неплохо добавить отображение блокировок Оркала.
Что бы видеть какой пользователь блокирует работу остальных.

А чем не устраивает
Главное меню \ Администрирование \ Запросы \ База данных \ Блокировки пользователей базы данных

[Logger]

А как этот вопрос решается в новых версиях Аксапты ?
В 2009-й указанный способ не работает.
(Вопрос о том как определить какая сессия на аосе сколько процессорного времени отъела)

[gl00mie]

В AX 2012 была добавлена возможность прописывать информацию о пользователе и его сессии в Аксапте в контекст SQL-соединения, за счет чего стало возможно со стороны СУБД понимать, какое соединение к кому относится, см. Troubleshooting database performance [AX 2012]. Заполнение контекста чуть-чуть снижает производительность, но это с лихвой компенсируется удобством мониторинга. После перезапуска АОСа с новой настройкой указанную информацию о сессии, доступную через sys.dm_exec_sessions.context_info, можно разбирать, к примеру, так:

PHP код:

WITH DM_EXEC_SESSION_PARSE (session_id, ax_user, ax_s)
AS (
SELECT
    session_id,
    SUBSTRING(CAST(ss.CONTEXT_INFO as varchar(128)), 2, PATINDEX('% %',
        LTRIM(CAST(ss.CONTEXT_INFO as varchar(128))))) as ax_user,
    CAST(SUBSTRING(LTRIM(CAST(ss.CONTEXT_INFO as varchar(128))),
        PATINDEX('% %', LTRIM(CAST(ss.CONTEXT_INFO as varchar(128)))) + 1,
        PATINDEX('% %', SUBSTRING(LTRIM(CAST(ss.CONTEXT_INFO as varchar(128))),
        PATINDEX('% %', LTRIM(CAST(ss.CONTEXT_INFO as varchar(128)))) + 1,
        LEN(CAST(ss.CONTEXT_INFO as varchar(128))))) - 1) as int) as ax_s
FROM    sys.dm_exec_sessions ss
WHERE    program_name in ('Microsoft Dynamics AX')
    AND    CAST(CONTEXT_INFO as varchar(128)) > ''
),
DM_EXEC_SESSION_FILTER (session_id, database_id, [status], threads)
AS (
    SELECT
        s.session_id
       ,s.database_id
       ,s.[status]
       ,count(*) as threads
    FROM    sys.dm_exec_sessions s
    JOIN    sys.dm_exec_requests r
        ON    (s.session_id = r.session_id AND r.sql_handle IS NOT NULL AND r.plan_handle IS NOT NULL)
        OR    (s.session_id = r.blocking_session_id)
    JOIN    sys.sysprocesses    sp
        ON    s.session_id = sp.spid
    GROUP BY s.session_id, s.database_id, s.status
)
SELECT
     ss.session_id AS [sid]
    ,COALESCE(r.blocking_session_id, 0) AS [blck]
    ,ss.threads
    ,COALESCE(ss_ctx.ax_user, '') AS [ax_user]
    ,COALESCE(ss_ctx.ax_s, '') AS [ax_s]
    ,COALESCE(r.wait_time, 0) AS [wait_time]
    ,COALESCE(r.wait_type, '') AS [wait_type]
    ,COALESCE(r.command, '') AS [command]
    ,ss.status as [status]
    ,COALESCE(DB_NAME(ss.database_id), '') as [db_name]
    ,CASE WHEN r.plan_handle IS NOT NULL THEN COALESCE((SELECT TOP 1 query_plan    FROM sys.dm_exec_query_plan(r.plan_handle)), '') ELSE '' END AS [query_plan]
    ,CASE WHEN r.sql_handle  IS NOT NULL THEN COALESCE((SELECT TOP 1 text        FROM sys.dm_exec_sql_text(r.sql_handle)), '') ELSE '' END AS [query]
FROM        DM_EXEC_SESSION_FILTER    ss
LEFT JOIN    sys.sysprocesses        sp
    ON    ss.session_id = sp.spid
    AND sp.loginame <> ''
LEFT JOIN    sys.dm_exec_requests    r
    ON    ss.session_id = r.session_id
LEFT JOIN    DM_EXEC_SESSION_PARSE    ss_ctx
    ON    ss_ctx.session_id = ss.session_id 


sid  blck  threads  ax_user  ax_s  wait_time  wait_type  command  status   db_name  query_plan                           query
---- ----- -------- -------- ----- ---------- ---------- -------- -------- -------- ------------------------------------ ----------
223  0     1        userId   123   0                     SELECT   running  AX60_DB  <ShowPlanXML xmlns="http://schema... SELECT ...

[gl00mie]

Собственно, это что касается связи пользователей и сессий СУБД
А по поводу загрузки пользователями процов на АОСе - никак. Потому что после 4.0, где перевели обработку бизнес-логики на рельсы RPC, на АОСе больше нет выделенного потока, закрепленного за каждой пользовательской сессией, вместо этого есть пул рабочих потоков (их в разы меньше, чем пользовательских сессий), где очередной запрос от пользовательской сессии обрабатывается первым попавшимся свободным рабочим потоком, который берется из пула, потом он кладется обратно в пул, а через мгновение уже обрабатывает запрос от другой пользовательской сессии. Чтобы АОС умел считать, какой пользователь насколько грузит его процессоры, он должен был бы вести некие счетчики производительности в разрезе пользовательских сессий.

[Logger]

Цитата:

Сообщение от gl00mie

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

Мммм. Если я правильно понимаю такое перескакивание может быть в случае когда от клиента идут запросы на аос и нет транзакции. А если начата транзакция или запущена долгая обработка на аосе (например пакет крутится) то тоже не будет соответствия сессии и потока ? Это же неудобно. Контекст надо как-то передавать между потоками. Накладные расходы опять же вырастают.
А где про это можно почитать ?

Цитата:

Сообщение от gl00mie

Чтобы АОС умел считать, какой пользователь насколько грузит его процессоры, он должен был бы вести некие счетчики производительности в разрезе пользовательских сессий.

Дык, вот и непонятно зачем этого не сделали. Тем более что, предыдущие версии аксапты такое позволяли делать (см. класс AOSSessionInfo)

[Logger]

Если нельзя, но очень хочется, то можно.

Поковырялся и все же сделал вариант мониторинга который частично решает поставленную задачу.
Исходим из того, что информация о загрузке аоса по сессиям интересует только тогда когда они создают существенную нагрузку, а это как правило:
1. Пакетные обработки.
2. Долгие серверные обработки, запущенные обычным пользователем.
3. Долгие серверные обработки инициированные com и .Net бизнес коннекторами.

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

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

Проект очень сырой, рассматриваю его как прототип. Возможны разные баги. Отображает нагрузку только на текущем аосе. Т.е. для просмотра процентов загрузки аоса сессиями, надо именно на интересующем аосе запускать форму.
Написан для 2009-й версии. Хотя возможно и для 2012-й сработает. я не проверял.

[Pustik]

Спасибо.
У меня при компиляции не хватает некоторых Ваших классов :
1) Session, Методы: Session::GRD_getAOSPortCached(), Session::GRD_getServerID()
Подойдет ли замена на Session::getAOSPort и return new xSession().serverId() соответственно?
2) SysTreeNode, Метод: SysTreeNode::GRD_refreshAll4Com();
Подойдет ли замена на SysTreeNode::refreshAll ?
3) Box, Метод: Box::yesNo_Net - но это вроде бы не критично
и нет таблиц :
GRD_BatchParameters, Метод : GRD_BatchParameters::find().MainBatchOperator
GRD_catch, Метод : GRD_catch::insertByCommon(.....

[Logger]

Там лишние методы попались. Можно их закомментировать. Нужно лишь помеченное номером проекта R100701 и все. Замены тоже должны подойти кроме SysTreeNode::GRD_refreshAll4Com().
Box::yesNo_Net - заменить на Box::yesNo

При работе выглядит примерно так для пакетных обработчиков


Перевыложил проект.

[MazZzDaI]

Создать таблицу, в которую писать имя коллера (форма, отчёт), пользователя, дату и время. Подвязать к событиям классов-родителей, например:
\Classes\SysSetupFormRun\run;
\Classes\SysSetupFormRun\closeOk;
\Classes\SysSetupFormRun\close;
\Classes\RunBase\run.

[trud]

Цитата:

Сообщение от Logger

Перевыложил проект.

Столкнулись с такой проблемой - периодически какой-то пользователь(а может и пакетное задание) приводит к высокой загрузке АОСа 2009, сжирает всю память на аосе(16ГБ) и начинает создавать кучу временных таблиц на диске.
АОС при этом не падает, но начинает жутко тормозить. на SQL загрузки тоже особо никакой нет.
Стоит задача определить что это за пользователь(ну или что за пакет).
Я так понимаю приложенный проект как раз нацелен на это. Поскольку тема старая - может у кого нибудь есть свежие идеи(ну или обновления проекта) как найти виновника
Выглядит это приметрно так (версия 2009)

[Logger]

Цитата:

Сообщение от trud

Я так понимаю приложенный проект как раз нацелен на это. Поскольку тема старая - может у кого нибудь есть свежие идеи(ну или обновления проекта) как найти виновника

Мой пример был нацелен на то чтобы найти того, кто сожрал процессорное время. В части поиска виновника потребления памяти, мне кажется, он не поможет.

Есть другие способы, попозже опишу. Но гарантированного результата не дают.

[fed]

Цитата:

Сообщение от trud

Столкнулись с такой проблемой - периодически какой-то пользователь(а может и пакетное задание) приводит к высокой загрузке АОСа 2009, сжирает всю память на аосе(16ГБ) и начинает создавать кучу временных таблиц на диске.
АОС при этом не падает, но начинает жутко тормозить. на SQL загрузки тоже особо никакой нет.
Стоит задача определить что это за пользователь(ну или что за пакет).
Я так понимаю приложенный проект как раз нацелен на это. Поскольку тема старая - может у кого нибудь есть свежие идеи(ну или обновления проекта) как найти виновника
Выглядит это приметрно так (версия 2009)
Вложение 12890

Я что-то такое видел, когда кто-то врубил EntireTableCache по часто обновляемой таблице. На SQL Server картина более или менее была (в целом - даже по таблице из 100000 записей выполнить select * from table не тяжело), но на AOSах творилось как-раз то, что у тебя описано. Один из AOS в кластере что-то в таблице обновляет, а другие видят какой-то семафор и бросаются таблицу читать с SQL и писать в временный файл. Попробуй посмотреть в кэше SQL Server, нету ли там каких-то загадочных (хотя и не очень затратных) полных селектов по таблицам, которые нету смысла целиком читать...

[Logger]

Цитата:

Сообщение от fed

Я что-то такое видел, когда кто-то врубил EntireTableCache по часто обновляемой таблице.

И оперативная память тоже поглощалась ?
А это-то почему ? Не должна бы.

[fed]

Цитата:

Сообщение от Logger

И оперативная память тоже поглощалась ?
А это-то почему ? Не должна бы.

Ну вообще в моем случае, AOS в памяти рос, но не до таких размеров. Есть подозрение что там кто-то эдак на десяточек-другой популярных таблиц врубил EntireTableCache, и вся память отъедается на постоянно создаваемые курсоры.
Хотя - это и что-то другое может быть. Но у меня картина довольно однозначная была на AOS - при довольно таки плевых с прикладной точки зрения операциях, загрузка CPU выростала до 40-60 процентов при 5-7 параллельно работающих пользователях.

[Raven Melancholic]

Цитата:

Сообщение от fed

Ну вообще в моем случае, AOS в памяти рос, но не до таких размеров. Есть подозрение что там кто-то эдак на десяточек-другой популярных таблиц врубил EntireTableCache, и вся память отъедается на постоянно создаваемые курсоры.
Хотя - это и что-то другое может быть. Но у меня картина довольно однозначная была на AOS - при довольно таки плевых с прикладной точки зрения операциях, загрузка CPU выростала до 40-60 процентов при 5-7 параллельно работающих пользователях.

Вспомним историю:
формальные показатели включения cacheLookup EntireTable

[trud]

Цитата:

Сообщение от fed

Ну вообще в моем случае, AOS в памяти рос, но не до таких размеров. Есть подозрение что там кто-то эдак на десяточек-другой популярных таблиц врубил EntireTableCache, и вся память отъедается на постоянно создаваемые курсоры.

Бинго .

Спасибо, я как-то упустил этот момент. Но хочется отменить что современные сервера стали быстрее, тут система как-то дожила до 1млн записей.
Джоб для проверки(https://github.com/TrudAX/TRUDScript...re-table-cache ,проверьте свои системы

[Raven Melancholic]

Цитата:

Сообщение от trud

Бинго .

Ух ты, а что за бизнес-ситуация при которой в InterCompanyEndpointActionPolicyTransfer такое количество записей?