AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 11.09.2018, 16:22   #1  
rashuf is offline
rashuf
Участник
 
14 / 15 (1) ++
Регистрация: 25.09.2013
Ax2009 SP1 RU6. Пользователи не могут зайти, но уже авторизованные продолжают работать
Добрый день!
DAX 2009 SP1 RU6, MS SQL 2012 Standard, Windows Server 2012 R2 Standard (и приложение, и база на одном физическом сервере). Все чаще (раньше - раз в пару недель, потом разв в неделю, теперь пару раз в неделю) наблюдается следующая картина - аксапта перестает "пускать" новых пользователей в аксапту, при этом уже авторизованные пользователи продолжают работать. "Не пускает" означает, что при запуске клиента он перестает отвечать - висит окно с заголовком и белым фоном. При наблюдении с помощью process monitor видно, что с клиентской машины уходит 2 пакета, и сервер на них отвечает. В TCP view соединение в статусе established. Порт открыт, база доступна. Служба не "падает". Но дальше этих двух пакетов процесс обмена между клиентом и сервером не идет. Устанавливали обновления ОС, настроен периодический перезапуск служб базы данных и приложений с удалением индексов. В логах ОС ничего, что хотя бы намекнуло на источник. Журнал SQL так же чист. Собирали дампы с помощью process explorer и debug diagnostic tools 2.2, анализировали с помощью скриптов (EMEADAXSupport ) в WinDbg - ничего (при критических падениях ранее эти скрипты помогли исправить ошибки). Нашел вот такую тему на форуме с похожей проблемой, но решения или описания источника в ней не нашел.
В чем может быть проблема? Кто-нибудь наблюдал такое поведение?
Старый 11.09.2018, 17:09   #2  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
У нас наблюдалось такое поведение чаще всего тогда, когда кто-то заходил в Аксапту с клиентом, версия которого ниже, чем у сервера.
Если такой пользователь заходил, то через некоторое время переставало пускать других. Может быть у Вас та же беда? Посмотрите значение поля BuildNum в таблице SysUserLog (ну или прямо в интерфейсе в запросах модуля Администрирование) у всех ли оно совпадает.
Старый 11.09.2018, 17:20   #3  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,860 / 3109 (111) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
У нас похожее бывало когда глючил DNS и сервер аоса вываливался из домена.
Старый 11.09.2018, 18:47   #4  
Wamr is offline
Wamr
----------------
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
 
1,737 / 858 (32) +++++++
Регистрация: 15.01.2002
Адрес: Москва
Записей в блоге: 7
Такое случалось, когда кто-то пытался открыть редактор меток, просмотр меток, импорт проекта на рабочем приложении.
За это сообщение автора поблагодарили: rashuf (1).
Старый 11.09.2018, 20:15   #5  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,649 / 1146 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Наверное, уже проверяли, но все-таки уточню. Ничего подозрительного в методах старта Axapta не делали?

- infolog.startup
- infolog.startupPost
- application.startup
- application.startupPost

При зависании, тем не менее, запись в логе входов пользователя создается?

Т.е., может, проблема не в системе, а в кривой кастомизации? Сделали какую-то обработку при входе, но не удачно и сейчас это проявилось...
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 12.09.2018, 08:04   #6  
rashuf is offline
rashuf
Участник
 
14 / 15 (1) ++
Регистрация: 25.09.2013
Thumbs up
Raven Melancholic,
действительно, есть несколько пользователей с BuildNum 1000.52 (при этом на сервере 1500.3761). Обновляем - ставим RU6. Но интересно, что раньше, когда приложение стояло на сервере 2008R2, "зависаний" не было. Кстати, в журнале Приложение ОС видно предупреждение с кодом 151 (Object Server 01: Internal aocp revision mismatch. Axapta client from PC310 (0.0.0.0) tried to attach with 5.0.1500.3761 revision of kernel)

Logger,
проверили DNS - вроде все нормально. Не может быть причиной проблемы с DNS на клиентах? Это проверим. Но в журналах контроллера домена никаких упоминаний на этот счет нет.

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

Владимир Максимов,
есть модификация на info.startupPost. Но код корректный. Запись в логах о входе пользователя не создается.

В общем, почти полный букет симптомов
Спасибо за отклик! Будем наблюдать, позже сообщу результаты.
Старый 18.09.2018, 14:41   #7  
rashuf is offline
rashuf
Участник
 
14 / 15 (1) ++
Регистрация: 25.09.2013
обновление клиентов не помогло
Добрый день!
Изменение версии клиентов (в 6 случаях - увеличение (поставили RU6), в одном - уменьшение (удалили одно KB)) на зависания не повлияло. Сегодня опять зависла служба.
В описании симптомов забыл упомянуть, что служба AIF, которая работает через BusinessConnector, мгновенно перестает отвечать. Это своего рода мониторинг зависаний
Хочу также поинтересоваться, используется ли такое сочетание ПО (Server 2012 Standard + MS SQL 2012 + DAX 2009 на одном сервере) у кого-нибудь еще? А то есть подозрение, что дело может быть в версии ОС. А пока потихоньку готовим запасной плацдарм в виде виртуальной Windows Server 2012 на Hyper-V. И будем убирать модификацию info.startupPost.
Старый 30.11.2018, 09:19   #8  
rashuf is offline
rashuf
Участник
 
14 / 15 (1) ++
Регистрация: 25.09.2013
Thumbs up
После нескольких месяцев наблюдений делаем следующие выводы.
Во-первых, после удаления модификации метода info.startupPost() "зависаний" стало гораздо меньше. Несколько раз было, но причины пока неясны.

Во-вторых, были падения службы AOS в момент, когда один из разработчиков пытался открыть редактор меток.

Считаю, что основная причина, отвественная за зависания в 90% случаев, выяснена - модификация info.startupPost().

Всем спасибо за помощь!
Старый 30.11.2018, 10:40   #9  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
А какой код там был?
__________________
Ivanhoe as is..
Старый 30.11.2018, 12:26   #10  
rashuf is offline
rashuf
Участник
 
14 / 15 (1) ++
Регистрация: 25.09.2013
Вот этот метод вызвался в startupPost
X++:
boolean closeOpenSession_flx()
{
    int             counter = 0,num;
    int             curSessions,maxSessions;
    int             curSessionId = new xSession().sessionId();
    container       users;
    userId          userId;
    Session         sessionToTerm;
    xSession        session;
    Container       userCon,activeUserCon;
    UserInfo        userInfo;
    ;

    counter = Info::licensedUsersTotal();
    userCon = SysUserInfo::getFullLicense();
    maxSessions = counter - conlen(userCon);
    curSessions = Info::getAllOnlineUser();
    userid = curuserid();
    // Проверка лицензий для приоритетных пользователей
    if (!confind(userCon,curuserid()) && curSessions >= maxSessions )
    {
        sessionToTerm = new Session(curSessionId);
        sessionToTerm.terminate();
        sessionToTerm = NULL;
        box::stop(strfmt("%1! Программа не может быть запущена. Количество активных пользователей превышает количество лицензий. Попробуйте подключиться позже!",
                  xUserInfo::find().name), "Microsoft Dynamics AX Access Control");
        appl.globalCache().set(classstr(Info),identifierstr(Autologoff), true);
        infolog.shutDown(true);
        return true;
    }
    // Проверка повторного входа того же пользователя
    if (SysUserInfo::checkLicenseAccess(userid))
    {
        for(counter = 1; counter < maxSessions;counter++ )
        {
            session = new xSession(counter, true);
            if(session && session.userId() && session.clientKind()!= ClientType::WorkerThread)
            {
                select firstOnly userInfo
                    where userInfo.id == session.userId();

                if (userInfo && (userid == session.userId()))
                {
                    num++;
                }
            }
        }
    }
    if (num > 1)
    {
        box::stop(strfmt("%1! Программа не может быть запущена дважды!",
                  xUserInfo::find().name), "Microsoft Dynamics AX Access Control");
        appl.globalCache().set(classstr(Info),identifierstr(Autologoff), true);
        infolog.shutDown(true);
        return true;
    }
    return false;
}
X++:
if (this.closeOpenSession_flx())
{
    return;
}

Последний раз редактировалось rashuf; 30.11.2018 в 12:28.
Старый 25.12.2018, 14:24   #11  
rashuf is offline
rashuf
Участник
 
14 / 15 (1) ++
Регистрация: 25.09.2013
Добрый день!

Ситуация после удаления кода из info.startupPost() улучшилась, но в последнее время стали замечать, что зависания опять учащаются. Есть какие-нибудь предложения/идеи, в чем может быть причина?

У нас же пока только одна идея, как можно исправить - мигрировать на виртуальную машину с Win2008r2.
Старый 26.12.2018, 16:14   #12  
Weez is offline
Weez
Участник
Axapta Retail User
 
250 / 84 (3) ++++
Регистрация: 18.01.2006
Адрес: Moscow city
Комбинация Server 2012 Standard + MS SQL 2012 + DAX 2009 - рабочая, по своему опыту говорю.
__________________
Существует 10 типов людей: одни понимают двоичную систему, другие - нет.
Старый 23.01.2019, 12:34   #13  
rashuf is offline
rashuf
Участник
 
14 / 15 (1) ++
Регистрация: 25.09.2013
Продолжаем поиск источника "висов".
В процессе обнаружил описание похожего случая. Встречались с таким? Но я так понял, что на AOS описанная проблема не влияла, только клиент на одной конкретной машине.
Пока же сосредоточились на решении конкретной проблемы - зависания при импорте проекта или просмотре меток, о чем писал Wamr. У кого-нибудь встречалось такое же поведение и есть ли решение хотя бы этой проблемы?
Еще поинтересуюсь - проводите ли какие-нибудь процедуры на сервере AOS, кроме резервного копирования? Например, у нас это еженедельный перенос доработок копированием приложения (содержимое папки Appl). Перед этим в приложении-источнике запускается компиляция и удаляются индексы (*.ali,*.aoi,*.alt,*.ahi,*.khi,*.adi). При этом еще встречал совет удалять *.alc файлы. Пока удалили только в тестовой среде.

PS: Еще один симптом - после зависания в первую очередь отваливаются соединения BusinessConnector'а.
Старый 23.01.2019, 18:57   #14  
Maximin is offline
Maximin
NavAx
NavAx Club
 
408 / 341 (12) ++++++
Регистрация: 09.10.2002
Адрес: Москва
Почистите кэши АОСов, удалите .aoi, .alc. См. соответствующую тему- там готовый батник был.
Сделайте глобальную компиляцию ТОЧНО правильной совместимой версией клиента.
Перезапустите АОС.
Потом наблюдайте. Чудес тут мало бывает. Сертификаты еще истекшие проверить можно и есть ли доступ к crl.microsoft.com - на этапе логина зависания бывают до 2х минут. Клиент действительно совсем висит или просто тупит пару минут, а потом таки логинится?

P.S. А че - в Феликсе уже 2009я?
__________________
Жизнь прекрасна! Если, конечно, правильно подобрать антидепрессанты...
За это сообщение автора поблагодарили: Logger (1).
Старый 24.01.2019, 07:35   #15  
rashuf is offline
rashuf
Участник
 
14 / 15 (1) ++
Регистрация: 25.09.2013
Кэш AOSов чистим. Глобальную компиляцию делаем на сервере, версия клиента совпадает с версией ядра.
Клиент действительно зависает - ждали более 10 минут, толку нет - белый экран окна с заголовком Microsoft Dynamics Ax - 1, т.е. не указаны ни наименование приложения, ни обладатель лицензии (как при успешном запуске, при успешном логине).
Для чего нужен доступ к crl.microsoft.com? Но в любом случае доступ есть. Вот ответ

PHP код:
<Error>
<
Code>InvalidQueryParameterValue</Code>
<
Message>
Value for one of the query parameters specified in the request URI is invalidRequestId:e2c449d9-c01e-008d-599d-b30bd6000000 Time:2019-01-24T04:28:24.8298493Z
</Message>
<
QueryParameterName>comp</QueryParameterName>
<
QueryParameterValue/>
<
Reason/>
</
Error
Сертификатов просроченных очень много - и в личных, в промежуточных, и в корневых. В том числе СКБ Контур, ФСС (электронные больничные) и пр. Это может влиять? Ранее никогда не следили за ними. Они автоматически вроде обновляются..
Старый 24.01.2019, 08:51   #16  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,860 / 3109 (111) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Недавно джобили права. Замножили записи в accessrightslist
Стало тормозить и подписать на логине.
Проверьте такую причину тоже.
Старый 24.01.2019, 11:41   #17  
Maximin is offline
Maximin
NavAx
NavAx Club
 
408 / 341 (12) ++++++
Регистрация: 09.10.2002
Адрес: Москва
Цитата:
Сообщение от rashuf Посмотреть сообщение
Для чего нужен доступ к crl.microsoft.com?
Позволю себе дать ссылку на свой же тред:
Долгий запуск клиента Dynamics Ax - решение
Там еще много полезных советов.

А далее надо анализировать, что происходит сразу перед зависанием - какой запрос отправляется на SQL, что происходит на локальной машине (запустить Sysinternals Process Monitor или взять Sysinternals Process Explorer свежий).
Попробуйте отключите еще антивирус на сервере (если он там есть, вообще - это зло) и клиенте.
__________________
Жизнь прекрасна! Если, конечно, правильно подобрать антидепрессанты...

Последний раз редактировалось Maximin; 24.01.2019 в 11:44.
Старый 12.08.2019, 09:47   #18  
rashuf is offline
rashuf
Участник
 
14 / 15 (1) ++
Регистрация: 25.09.2013
С зависанием во время импорта, похоже, разобрались
Здравствуйте!
Локализовали причину "зависания".
Вообще наблюдали 2 типа зависания - во время импорта или просмотра меток и "случайный", без видимой причины.
Причиной в первом случае оказались битые файлы меток для всех языков, кроме русского. Битые, потому что в них были пропущены целые диапазоны меток, например, @RSL14643-@RSL14790, @RSL14799-@RSL15605 и др. Подозреваем, что эти блоки были пропущены во время автогенерации меток. Обнаружили, потому что аксапта зависала во время вызова SysLabel.new() для языка fr-ca. Мы просто удалили файлы всех языков для RSL-меток, кроме русского (*.ald-файлы). Проверили импорт - все нормально, не зависает. Удаленные файлы больше не создались (2 недели прошло). Правда, и новые метки пока не создаем и не импортируем.

Во втором случае блокируется таблица Batch. Выяснили с помощью AxTraceParser'а, стандартного отчета MS SQL Все транзакции/Все блокирующие транзакции и запроса.
AxTraceParser показал, что в сессии AOS последними запросами при логине клиента во время зависания являются выбор записи пользователя из UserInfo, вызов хранимой процедуры CREATEUSERSESSIONS и подсчет количества записей по пользователю в SysClientSessions. При этом при нормальной работе AOS еще "мелькают" запросы обновления Batch, BatchJob для запускаемых пакетных заданий. В зависшей сессии таких запросов нет. Пробовали завершать сессии в MS SQL с помощью kill, закрывать порты (TCP-порты 2719) с помощью CurrPorts. Эти меры не помогают "пробудить" AOS, и потом при подключении клиентов выходит ошибка, что AOS вроде бы недоступен, при этом служба работает.

Я видел, что есть исправление KB 3216955 Continuous dead locks in batch tables. Обсуждалось на форуме. Возможно, портирование этого исправления нам тоже поможет, но я не смог его найти (нет доступа) и не понял из сообщения gl00mie, что и где поменялось.
Коллеги, кто-нибудь занимался адаптацией этого обновления на AX 2009? Что изменилось? Может, с учетом новых наблюдений, вообще в другую сторону надо копать?

PS: запрос
Код:
SELECT 
	L.request_session_id               AS SPID, 
	DB_NAME(L.resource_database_id)    AS DatabaseName,
	O.Name                             AS LockedObjectName, 
	P.object_id                        AS LockedObjectId, 
	L.resource_type                    AS LockedResource, 
	L.request_mode                     AS LockType,
	ST.text                            AS SqlStatementText,        
	ES.login_name                      AS LoginName,
	ES.host_name                       AS HostName,
	TST.is_user_transaction            AS IsUserTransaction,
	AT.name                            AS TransactionName,
	CN.auth_scheme                     AS AuthenticationMethod
	FROM sys.dm_tran_locks L
    
	JOIN sys.partitions P
		ON P.hobt_id = L.resource_associated_entity_id
    
	JOIN sys.objects O
		ON O.object_id = P.object_id
    
	JOIN sys.dm_exec_sessions ES
		ON ES.session_id = L.request_session_id
    
	JOIN sys.dm_tran_session_transactions TST
		ON ES.session_id = TST.session_id
    
	JOIN sys.dm_tran_active_transactions AT
		ON TST.transaction_id = AT.transaction_id
    
	JOIN sys.dm_exec_connections CN
		ON CN.session_id = ES.session_id
    
	CROSS APPLY sys.dm_exec_sql_text(CN.most_recent_sql_handle) AS ST
	
	WHERE resource_database_id = db_id()

ORDER BY L.request_session_id
Теги
ax2009, зависание

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
AX2009 как работать с элементом Window Arahnid DAX: Администрирование 2 14.09.2014 14:59
Dynamics AX Sustained Engineering: Individual patching for Dynamics AX2009 SP1 industry solutions Blog bot DAX Blogs 0 13.06.2012 10:11
axinthefield: Choosing a Single Deployment or Multiple Deployments of AX2009 Blog bot DAX Blogs 0 15.06.2011 03:25
Ax2009 SP1 RU6. LedgerBalanceSum_CurrentMST.buildQuery(). Ошибка при пустой начальной дате Damn DAX: Программирование 11 30.03.2011 16:15
Почему не могут зайти пользователи Excel 2003 на OLAP 2005? mazzy DAX: Администрирование 4 30.08.2007 10:35
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 12:36.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.