Общие сведения

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

Рис. 1. Буферы системы SAP.

Использование буферов на уровне сервера приложений SAP даёт ряд важных преимуществ:

• увеличение быстродействия при чтении данных: доступ к SAP буферу обычно в 10-100 раз быстрее, чем к базе данных,
• уменьшение нагрузки на базу данных с увеличением производительности всей системы в целом,
• уменьшение очереди ABAP диспетчера, как следствие, уменьшения времени обработки каждого шага диалога рабочими процессами, и более быстрое переключение между задачами.

Все SAP буферы можно разделить на три категории:

• системные,
• буферы для объектно-ориентированных приложений,
• табличные.

Детальную информацию по буферам SAP инстанции и уровне их влияния на производительностьсистемы можно найти в таблице (рис. 2).

Рис. 2. Буферы сервера приложений SAP с описанием.

Мониторинг буферов SAP инстанции производится с помощью транзакции ST02 (рис. 3).

Рис. 3. Мониторинг буферов SAP в транзакции ST02.

У каждого буфера есть два параметра: размер самого буфера (общий - Allocated и свободный - Free space) и количество записей в нём (максимальное - Dir. size Entries и свободное - Free directory Entries).

Для каждого буфера доступна детальная информация: для перехода к детальному экрану необходимо дважды щелкнуть на строку с названием буфера (рис. 4).

Рис. 4. Детальная информация о буфере TTAB.

Нажав соответствующую кнопку на панели, можно получить доступ к истории использования буфера (рис. 5).

Рис. 5. История использования буфера TTAB.

При анализе работы буфера необходимо отслеживать два параметра:

• коэффициент попадания (hitratio), который показывает эффективность работы буфера,
• вытеснения из буфера (swaps).

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

Вытеснения из буфера, количество которых фиксируется в поле "Swaps", происходит в момент нехватки в буфере места или свободного количества записей (поле "Free directory Entries").

Основные рекомендации при мониторинге буферов:

1. Коэффициент попадания (hit ratio) должен быть не ниже 95 %. Для Nametab (NTAB) буферов точность должна быть минимум 99,5 %.
2. Буферы должны быть достаточного, но не слишком большого размера (размер буфера и количество записей).
3. Количество вытеснений из буфера (swaps) не должно значимо отличаться от 0.

Для уменьшения количества swaps необходимо увеличить размер буфера или количество записей в буфере, в зависимости от того, чего именно не хватает. На приведённом примере (рис. 3) для буфера "Export/Import" большое количество вытеснений (swaps) обусловлено нехваткой свободных записей в буфере ("Free directory Entries").

Изменение размеров буфера производится через параметры SAP системы. Список параметров доступен по кнопке "Current Parameters" на основном экране транзакции ST02 (рис. 6).

Рис. 6. Список параметров инстанции для настройки буферов системы SAP.

Изменение размеров буферов рекомендуется проводить в диапазоне 10-50 % от начального значения, после чего проводить мониторинг (после минимум недельной работы SAP инстанции). Перед установкой любого параметра необходимо изучить справку по нему в транзакции RZ11 и на SAP Help Portal. А также учитывать единицы измерения - байт, Кб, блоки по 8 Кб.

Полезные SAP notes по  теме статьи:

• 625305 - Profile parameters for the error analysis buffer,
• 702728 - Profile parameters for export/import buffer instances.

Программный буфер

Исполняемую часть ABAP стека SAP системы можно разделить на 2 компоненты:

• ядро (SAP Kernel), написанное на языке C++,
• программы, написанные на языке ABAP.

SAP Kernel представляет собой набор исполняемых файлов, зависимых от платформы, на которой работает текущая SAP система. Под платформой подразумевается связка "архитектура сервера - операционная система - база данных". Например, "сервер HP PA_RISC 64 bit - ОС HP-UX 11.31 64 bit - БД ORACLE 11g".

Поддерживаемые платформы для каждой SAP системы можно найти в PAM (подробности в этом посте).

ABAP программы поставляются в виде исходных кодов и хранятся в таблицах базы данных. Для примера можно посмотреть таблицу REPOSRC - это основная таблица для исходных кодов программ.

В мире SAP существует своя внутренняя нумерация платформ (в данном случае, версия базы данных не учитывается). Платформу текущей системы можно найти, если в SAP GUI перейти в пункт меню "System -> Status"

Рис. 7. Примеры платформ SAP систем.

Для того чтобы рабочий процесс SAP инстанции ("ABAP процессор") мог выполнить код ABAP программы, необходимо для неё сгенерировать ABAP load. ABAP loads генерируются для каждой платформы (Platform ID). Если программа ни разу не запускалась в данной SAP системе или текущий ABAP load был сгенерирован для другой платформы, то при запуске программы будет затрачено время на автоматическую генерацию ABAP load, а в строке состояния будет соответствующее сообщение (рис. 8).

Рис. 8. Генерация ABAP Program Load.

Обычно SAP система работает на одной платформе, но в случае гетерогенной среды, когда сервера приложений расположены на разных платформах, генерируемый объём ABAP loads будет выше, так как в системе будут одновременно храниться ABAP loads для разных платформ.

Возможна централизованная массовая генерация ABAP loads с помощью SAP Load Generator (транзакции SGEN). Подробности можно найти в справке или в SAP note # 481548 - Mass generation for new load format.

Рабочий процесс считывает ABAP loads из специального буфера SAP инстанции, который называется Program buffer, Program Execution Area (сокращенно PXA) или просто ABAP buffer. Буферизация позволяет существенно снизить время доступа к программам при выполнении. Все SAP буферы создаются в рамках одной инстанции.

Рабочие процессы могут считывать ABAP loads только из этого буфера. Если место в буфере заканчивается, то последний используемый load удаляется (для выборки используется алгоритм LRU). Такое удаление фиксируется, как swaps.

Мониторинг программного буфера осуществляется посредством транзакции ST02 (рис. 9).

Рис. 9. Мониторинг Program Buffer в ST02.

По двойному щелчку на строку с именем буфера можно посмотреть детали (рис. 10).

Рис. 10. Детальная информация по Program Buffer в ST02.

Если нажать последовательность кнопок "Buffered objects -> PXA buffer technical", то можно увидеть список ABAP loads, содержащихся в буфере (рис. 11).

Рис. 11. Список программ в Program Buffer.

Большинство программ имеют небольшой размер (до 8 Кб), но потенциальный размер всех ABAP loads SAP системы может быть очень большим (несколько Гб). Поэтому, несмотря на большой размер PXA буфера (например, 1000 Мб), могут наблюдаться swaps. При невозможности увеличить размер буфера допускается до 10 000 swaps в день. Такое количество swaps не приводит к сильному провалу производительности системы.

За размер буфера отвечает один параметр - abap/buffersize (рис. 6). Размера буфера указывается в Кб, а максимальное количество объектов в буфере (Directory Size) рассчитывается как четвертая часть от размера. Например, при размере буфера 640 000 Кб, Directory Size - 160 000 (рис. 12).

Рис. 12. Параметры для настройки Program Buffer.

Точность буфера (коэффициент попадания HitRatio) должна быть не меньше 95 %, иначе вырастет доля "load and generation time" во времени отклика системы. Точность может уменьшаться при импорте новых исходников ABAP программ (особенно, при импорте пакетов поддержки или