Комментарии по теме

«Тра­нза­кция SM02: сообщения в SAP системе»
Олег Башкатов:
С помощью ФМ TH_POPUP можно отправить сообщение конкретному пользователю :-)
«Тра­нспо­ртная система SAP для чайников»
Вячеслав Шиболов:
Хорошая метафора с коробками. Наглядная.

База знаний

Вы можете подписаться на эту колонки этого автора, если авторизируетесь или зарегистрируетесь

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

21 ноября 2015, 03:21

В первой части статьи про организацию памяти в 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.

Функциональная область : Информационные технологии / IT, Basis, ABAP

Ключевые слова : Администрирование ABAP / ABAP Administration

Ролевое назначение : SAP Консультант / Consultant

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

Денис Озорнов (Рейтинг: 384) 10:19, 24 ноября 2015

У вас написано, что контекст хранит данные SET\GET параметров пользователя и что при открытии нового окна в рамках одного логина происходит создание обособленной копии контекста. Скажите пожалуйста, как это согласуется  тем, что изменение SET\GET параметра в одном окне видно и во втором? Т.е. я открыл новое окно, в нем выполнил действие устанавливающее значение параметра, и если переключаюсь на начальное окно и вызываю транзакцию считывающую значение этого параметра, то я получаю в первом окне значение введенное во втором окне.
11:18, 24 ноября 2015

Вячеслав Шиболов (Рейтинг: 750)

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