Падает аос 2009

[Logger]

Добрый вечер.

Коллеги, подскажите из-за чего может падать аос аксапты 2009, не оставляя никаких дампов?

Сбор дампов настроили по инструкции
https://web.archive.org/web/20150630...processes.aspx

если его вручную ронять серверным джобом
Классы коллекций (инициализация, сериализация): List, Set, Map.
дамп собирается.

А при реальном падении в работе - дамп не собирается.
Причем падает часто не один аос а несколько аосов внутри сервака.

Ошибка в логах примерно такого вида
Object Server 02: I/O Error 59 (OS error ) occured when session 46074 accessed \\fileShara\shares$\AxXXXX_Application\appl\MDAX_YYYY\axapd.aoi.
Object Server 01: I/O Error 59 (OS error ) occured when session 212 accessed \\fileShara\shares$\AxXXXX_Application\appl\MDAX_YYYY\axcus.aod.

[SRF]

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

https://dba.stackexchange.com/questi...twork-error-59

[Logger]

Ситуация похоже связана с тем, что при автоматической миграции виртуальных машин с железки на железку и при бекапировании (сперва идет снапшот и все фризится на несколько секунд) - аосы внутри сервера дружно падают. Видимо не могут фриз пережить.
Но проблема в том что это тоже носит случайный характер.
Сегодня фриз был на 8 секунд и ничего не упало.
А завтра 3 секунды - и аосы внутри сервака осыпались.

Есть ли какая-нибудь настройка, которая может помочь, чтобы аос не воспринимал ситуацию фриза как проблемную.

[vmoskalenko]

Цитата:

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

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

Есть ли какая-нибудь настройка, которая может помочь, чтобы аос не воспринимал ситуацию фриза как проблемную.

К сожалению не знаю такую настройку для AX 2012.
Была аналогичная проблема когда ставили windows кластер для SQL кластера. Там был такой параметр как через какое время считать сеть упавшей. Стояло 3 секунды - поменяли на 15 секунд и падения перестали.

Но корень проблемы-то не в AX 2012, а в VMWare и в бекапировании...

[SRF]

Для 2012 настройка не так актуальна скорее всего, как для 2009, поскольку приложение в БД находится, и видимо не так остро реагирует на фриз.

Могу вот такой пример привести - для 2012 ночью делается бекап ВМ ежедневно в одно и тоже время, это генерит два коротких фриза, в EV потом можно наблюдать какие то ошибки с запросами к БД, падение каких то сессий иногда, и целом всё, АОСы работают как ни в чем не бывало, не падают.

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

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

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

Конечно хотелось бы, чтобы подобные прерывания не приводили к падению АОСов, но что есть то есть.

[Logger]

Цитата:

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

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

https://dba.stackexchange.com/questi...twork-error-59

Была проблема с сетью.
Падала сеть.
Обновили драйвера на хостах под которыми крутятся виртуалки и все нормализовалось.