Организация памяти в SAP AS ABAP - II

В первой части статьи про организацию памяти в SAP системе я обрисовал общую картину. Теперь вы знаете, что в SAP системе существует понятие виртуальной памяти, которая состоит из общей (Shared memory) и локальной (Local memory) памяти. Основные области памяти были также обозначены. Продолжим.

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

Во время входа в SAP систему каждый пользователь занимает небольшой объем памяти, который называется контекстом или начальным контекстом пользователя. В данном объеме памяти хранятся такие данные, как полномочия пользователя, значения SET/GET параметров и т.п. Во время работы пользователя в системе к его контексту добавляются данные необходимые для работы транзакций, например, номера документов. Логически и физически контекст каждого пользователя хранится в Roll area.

Стоит отметить, что когда пользователь открывает еще одну сессию (режим работы) в рамках одного логина в систему, нажимая в SAP GUI на панели кнопку "Create new session" (рис. 1), то создается еще одна копия контекста пользователя. Обе копии хранят данные отдельно друг от друга.

Рис. 1. Открытие новой сессии.

Все запросы от пользователей (шаги диалога) попадают в очередь к диспетчеру рабочих процессов, или ABAP диспетчеру. Он выбирает свободный рабочий процесс, который будет выполнять шаг диалога конкретного пользователя. Для выполнения шага диалога рабочему процессу необходимы данные текущего пользователя - его контекст. Процесс копирования контекста из Roll area в локальную память рабочего процесса называется roll-in (рис. 2).

Рис. 2. Мультиплексирование рабочих процессов.

После выполнения шага диалога, контекст выгружается из локальной памяти обратно в Roll area. Данный процесс, в свою очередь, называется roll-out. Ну и как я уже упоминал в первой части, Roll area состоит из двух областей - буфер в памяти и физический файл.

Последовательность выделения памяти для шага диалога в рамках рабочего процесса диалога (DIA WP) представлена на рис. 3.

Рис. 3. Выделение памяти для диалогового рабочего процесса.

1. Сначала для пользователя выделяется небольшой объем Roll area, который задается параметром ztta/roll_first. При рекомендуемом значении ztta/roll_first = 1, выделяется минимальный размер: в зависимости от релиза системы это около 100-200 Кб.
2. Если размер контекста пользователя растет, то используется память Extended memory. Тут стоит отметить, что данная память не копируется из Shared области в локальную область рабочего процесса, а выделяется блоками (параметр em/blocksize_KB = 1024 - менять по собственной инициативе не рекомендуется), а в контексте пользователя хранятся только указатели (pointers) на блоки в Extended memory (maping). Это обеспечивает быстрое переключение контекстов (roll-in/roll-out).
3. Если контекст пользователя использует весь объем Extended memory, определенный в квоте на один шаг диалога (параметр ztta/roll_extension), то рабочий процесс начинает снова использовать локальную память в Roll area, до размера квоты, определенной параметром ztta/roll_area.
4. Если рабочему процессу необходимо еще больше памяти, то она выделяется в области SAP Heap memory (локальная память). С данного момента рабочий процесс переходит в PRIV режим (private mode). Это означает, что контекст пользователя не выгружается из рабочего процесса до тех пор, пока не будут выполнены все диалоговые шаги транзакции. Таким образом, данный рабочий процесс выпадает из цикла мультиплексирования и становится персональным для текущего пользователя. Подробности тут.
5. Если рабочему процессу необходимо SAP Heap memory больше, чем сконфигурировано в квоте, определенной параметром abap/heap_area_dia, то программа прерывается с дампом, сообщающем о нехватке памяти.

Данная схема выделения памяти используется в диалоговых рабочих процессах на всех платформах и не-диалоговых рабочих процессах в операционной системе MS Windows.

Для не-диалоговых рабочих процессов в Unix картина несколько иная (рис. 4).

Рис. 4. Схема выделения памяти для не-диалоговых рабочих процессов в Unix.

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


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