Периодически почти в любой SAP системе возникают ошибки, дампы и сбои. Не возникает их, наверное, только в системе, где никто не работает. А для надёжности в системе, которая вообще выключена. :)
Бывает ситуация, когда рабочий процесс ABAP инстанции "падает" с кодом ошибки 11, а в SAP системе формируется динамическая ошибка типа SYSTEM_CORE_DUMPED (рис. 1).
Рис. 1. Пример дампа SYSTEM_CORE_DUMPED. |
В результате сбоя рабочий процесс останавливается, а на уровне файловой системы в рабочей директории инстанции (/usr/sap/<SID>/<Instance>/work/) образуется файл, содержащий дамп памяти и имеющий имя - core. Рабочий процесс обычно автоматически перезапускается диспетчером и о фактах рестарта мы можем узнать только по счётчику "Ошб." на экране транзакции SM50 (рис. 2).
Рис. 2. Информация о рестарте рабочего процесса в результате сбоя. |
Про поиск core файлов на уровне операционной системы я писал ещё в посте "HP-UX. Многоликая команда find". Данная команда одинаково работает в любой Unix или Linux системе. Но иногда файлы core имеют большой размер и могут даже переполнить файловую систему (рис. 3).
Рис. 3. Пример core файла на уровне операционной системы. |
В моём примере файл core имеет размер 39 Гб, что составляет более половины размера файловой системы. Если же на ваших серверах приложений данная файловая система имеет размер недостаточный для создаваемых файлов дампов и, из-за этих файлов часто происходит переполнение файловой системы, то можно после очередного удаления файла core создать его заранее в виде линка на /dev/null (рис. 4).
Рис. 4. Решение по хранению больших core файлов. |
В этом случае всё содержимое core файла будет уходить в никуда, не занимая места ни в одной из файловых систем сервера.
Автор: Шиболов Вячеслав Анатольевич
Комментариев нет:
Отправить комментарий