Сегодняшним постом я снова обращусь к теме организации памяти на сервере приложений 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 можно проигнорировать. Главное, чтобы вы были уверены в том, что делаете и понимали базовые процессы в системе.
Автор: Шиболов Вячеслав Анатольевич
Комментариев нет:
Отправить комментарий