4 мая 2021 г.

Когда возникает системный дамп MEMORY_NO_MORE_PAGING

Сегодняшним постом я снова обращусь к теме организации памяти на сервере приложений SAP AS ABAP. Поговорим про системный дамп MEMORY_NO_MORE_PAGING. Обычно такой дамп возникает не один, а генерируется массово. Причём одновременно у нескольких пользователей одной SAP инстанции (рис. 1 и 2).  

Рис. 1. Пример генерации системных дампов типа MEMORY_NO_MORE_PAGING.

Рис. 2. Пример системного дампа MEMORY_NO_MORE_PAGING.

Данный сбой происходит тогда, когда рабочий процесс инстанции SAP системы, выполняющий ABAP-код, не может получить очередную порцию памяти из Paging Area (или SAP paging memory). В данной области хранятся временные ABAP объекты (Data clusters и параметры для вызывающих программ и транзакций), создаваемые во время выполнения операндов вида IMPORT/EXPORT FROM/TO MEMORY, SUBMIT REPORT, CALL TRANSACTION, CALL DIALOG и так далее (рис. 3). Про эту область я уже упоминал в нескольких своих постах (ссылка 1, ссылка 2).

Рис. 3. Примеры операндов, использующих Paging Area.

Анализ текущего размера и использования Paging Area осуществляется в транзакции ST02 (рис. 4).  

Рис. 4. Мониторинг использования Paging Area.

Возможен так же просмотр не только текущего и максимально использованного размера области, но и исторических данных. Для этого необходимо дважды щелкнуть мышью на имя области "Paging area". По информации на открывшемся экране можно проанализировать, например, в какой день использование данной области достигло своего максимума (рис. 5).

Рис. 5. История использования Roll и Page областей инстанции.

Как вы можете заметить, данные в историю попадают каждый день в 22:28. А это явно не пиковое рабочее время системы. Поэтому большого смысла анализировать значения в поле "Used" на этом экране нет.

Paging Area состоит из двух частей: область в памяти - SAP paging buffer и файл на уровне сервера приложений - SAP paging file. В данном случае (рис. 4) можно заметить, что область заполнена почти на 94%. И если рабочие процессы текущей инстанции будут запрашивать место в Paging Area и дальше (но при этом не освобождать его), то область переполнится. И, как результат, в системе начнут генерироваться системные дампы типа MEMORY_NO_MORE_PAGING (рис. 1 и 2). 

Настройка размера области производится с помощью двух параметров инстанции: rdisp/PG_SHM и rdisp/PG_MAXFS. Единица измерения - блоки по 8 Кб. Первый параметр задаёт размер области Paging Area в оперативной памяти, а второй - общий размер, равный сумме Paging buffer и Paging file. При этом местоположение файла задаётся через параметр DIR_REORG. По умолчанию это /usr/sap/<SID>/<Instance>/data, а имя файла - PAGFIL<Instance_number>.

Чем больше будет часть Paging Area находящаяся в оперативной памяти, тем выше будет производительность операций при работе с ней. В идеале, можно выставить rdisp/PG_SHM = rdisp/PG_MAXFS. Как вы понимаете, в этом случае вся область будет располагаться в оперативной памяти. 

Таким образом, для решения обозначенной в начале поста проблемы, когда в системе генерируются дампы типа MEMORY_NO_MORE_PAGING, достаточно увеличить размер Paging Area. 

Но здесь кроется одна проблема. На системах, основанных на SAP NetWeaver версии 7.0 и ниже, максимальное значение параметра rdisp/PG_MAXFS указано равным 262 144 (рис. 6). Это соответствует размеру области равному 262 144 * 8 Кб = 2 Гб.  

Рис. 6. Описание параметра rdisp/PG_MAXFS в системе SAP NetWeaver 7.0.

Я столкнулся с тем, что на инстанции SAP системы периодически не хватает Paging Area, состоящей из 1,5 Гб в оперативной памяти плюс 500 Мб на диске. И получается, что дальше увеличивать область нельзя.

В этом случае, конечно, можно было бы пойти к ABAP-разработчикам и начать их учить программировать. :) Сказать, что я  со своей стороны сделал, всё что мог, переписывайте программы. Но программировать на ABAP я не умею, да и переписать программу процесс длительный. Поэтому для начала я решил разобраться: а что ещё можно сделать с моей позиции. И нашёл пару SAP notes: 

В этих документах сказано, что ограничение на параметр наложено из-за поддержки 32-битных систем. Такая разрядность систем ограничивает область памяти процесса 2 Гб. Но на практике, даже на такой системе, можно устанавливать размер области = 2 Гб + область памяти. То есть ограничение можно записать в виде rdisp/PG_MAXFS = 250 000 + rdisp/PG_SHM. Параметр rdisp/PG_SHM, в свою очередь, тоже может быть 2 Гб. 

А для 64-битных систем нет даже таких ограничений. Главное, чтобы файловая система поддерживала файлы размером больше 2 Гб. Ну, а предупреждение в транзакции RZ10, можно проигнорировать. 

Аналогичные утверждения верны и для области Roll Area.

В SAP NetWeaver 7.50 такого ограничения уже нет. Может быть в системах между этими релизами то же где-то увеличили максимальное значение. Не удивлюсь, если это было сделано в SAP NetWeaver 7.40. Но, согласно описанию параметра в SAP NetWeaver 7.50, Paging Area уже может достигать 12 500 000 * 8 Кб = 95 Гб (рис. 7).

Рис. 7. Описание параметра rdisp/PG_MAXFS в системе SAP NetWeaver 7.5.

А я на своей старой системе, не смотря на максимальное ограничение в 2 Гб, настроил новый размер Paging Area равный 2 Гб в оперативной памяти и 1 Гб на файловой системе:
rdisp/PG_SHM = 250 000
rdisp/PG_MAXFS = 375 000
Изменения системой после рестарта подхватились успешно (рис. 8). Буду наблюдать за работой системы дальше.

Рис. 8. Размер Paging Area после изменения параметров.

Настроив Paging Area таким образом, теперь уже можно пойти к программистам и научить их программировать попросить их проанализировать код программ на предмет оптимизации использования данного вида памяти. И задача из критической превращается в плановую.

Одновременно из этой истории можно сделать такой вывод: иногда, при установке параметров SAP инстанции предупреждения в RZ10 можно проигнорировать. Главное, чтобы вы были уверены в том, что делаете и понимали базовые процессы в системе. 

Автор: Шиболов Вячеслав Анатольевич


Комментариев нет:

Отправить комментарий