Тюнинг настроек памяти AS ABAP инстанции на реальном примере

В моём блоге можно найти несколько хороших статей про организацию памяти в AS ABAP инстанции. Во первых, это цикл статей, ссылки на которые доступны в посте "Организация памяти в SAP AS ABAP. Заключение", а во вторых, статьи про буферы инстанции - "SAP буферизация. Заключение". Если вы не читали их, то настоятельно рекомендую ознакомиться.

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

Про важность настройки размеров буферов для базы данных Oracle я уже писал в этом посте. 

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

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

Рис. 1. Список рабочих процессов в PRIV режиме.

Для начала необходимо собрать информацию о системе. Версия SAP системы - SAP ERP 6.0 с SAP_BASIS 700 и ядром 7.22 (рис. 2-4).

Рис. 2. Информация по версии системы - 1.

Рис. 3. Информация по версии системы - 2.

Рис. 4. Информация по версии системы - 3.

Платформа, как видно из этих же скриншотов, Solaris (SunOS 5.11), а в качестве базы данных используется Oracle 11.2. 

Основные навыки работы с буферами и областями памяти в SAP инстанции от платформы зависят не сильно, и, в основном, идентичны для всех версий системы.

Оперативной памяти на сервере достаточное количество - 256 Гб (рис. 5). Памяти на уровне операционной системы хватает - область подкачки не используется (рис. 6). При этом мне известно, что весь сервер отдан текущей SAP системе, включающей в себя сервер базы данных и центральную инстанцию SAP.

Рис. 5. Информация из транзакции ST06.

Рис. 6. Вывод команды top на уровне операционной системы сервера. 

Я не знаком с особенностями и нюансами работы с оперативной памятью в операционной системе Solaris, но буду исходить из общих знаний работы Unix с памятью. Читали мой пост про оперативную память в Linux? Всё, что не отдано приложениям, операционная система использует под свои буферы, в частности, под файловый кэш. Но тут мы видим, что даже с учётом этого свободно 12 Гб оперативной памяти. И самый главный критерий, повторюсь, полностью свободная swap область.

Основным буферам базы данных Oracle отдано порядка - 35 Гб и 36 Гб (рис. 7). Суммарно получается около 71 Гб, что так же можно наблюдать у процессов "oracle" на уровне операционной системы (рис. 6). Целесообразность размеров буферов базы данных я здесь рассматривать не буду. У SAP есть рекомендации по параметрам базы данных Oracle, которые отражены в соответствующих SAP notes (вот эта статья, рис. 1). Отмечу лишь тот факт, что хорошая эффективность буфера в текущей системе подтверждена соотношением физических и логических чтений из базы данных (рис. 7). 

Для решения текущей задачи фиксируем, что серверу базы данных отдано порядка 71 Гб общей оперативной памяти. Значит, серверу приложений SAP можно отдать не меньше.

Рис. 7. Информация по производительности Oracle из транзакции ST06.

Вернувшись к основной проблеме, напомню, что переход рабочего процесса в PRIV режим происходит тогда, когда ему не хватает памяти из области Extended Memory и он начинает использовать SAP Heap Memory. Кто не помнит, читаем вот этот пост. Это может происходить, если квота, ограничивающая процессу память из Extended Memory, мала, или же, когда размер этой области слишком мал для текущего количества работающих в системе пользователей.

Основной инструмент для мониторинга использования памяти и буферов SAP инстанции это транзакция ST02. Заглянем в неё на текущей системе (рис. 8). 

Первое на что надо смотреть - когда сделан информационный слепок по системе (1) и время последнего рестарта инстанции (2). Так как во время рестарта происходит сброс всех буферов инстанции и их содержимого соответственно. В данном случае инстанция работает больше 6 месяцев. И для анализа это хорошо. Для основательного анализа желательно, чтобы система работала как минимум пару недель. Тогда собранная статистика будет достаточна. 

Глядя на экран, первое, что бросается в глаза сразу, это большое количество вытеснений из буфера (swaps) для следующих буферов инстанции:

• Program buffer (3),
• CUA buffer (3),
• Screen buffer (3),
• Tables buffers - оба (4),
• Export/Import buffer (5).

Рис. 8. Снимок экрана транзакции ST02.

Читая документацию, можно сделать вывод, что определённое количество вытеснений из буферов допускается, но в идеале должно стремиться к нулю. К тому же, если вы заметите, данные буферы имеют очень небольшой размер, а влияние на производительность оказывают существенное. А текущий сервер, как мы уже выяснили, имеет на своём борту достаточное количество свободной оперативной памяти. Как мне кажется, наблюдаемые значения похожи на те, что устанавливаются в этой версии системы по умолчанию после установки, но они малы даже для систем разработки и настройки. 

Так что моя первая рекомендация в данном случае: увеличить вышеперечисленные буферы SAP инстанции. 

Обычно буфер определяется двумя параметрами: максимальный размер в байтах и максимальное количество хранимых записей (поля "Dir. Size"). Но при этом у Program Buffer и CUA Buffer один параметр - размер, а количество записей рассчитывается системой исходя из размера самого буфера. 

Текущие значения ключевых, в данном случае, параметров и рекомендации по их изменению представлены в таблице (рис. 9).

Рис. 9. Рекомендации по настройке буферов SAP инстанции.

Теперь переходим к общей памяти (рис. 8, поле 6). По многим областям зафиксировано достижение максимального размера областей (поле "MaxUse [KB]"). Это означает, что хотя бы однажды за период мониторинга данные заполняли буфер полностью и системе его не хватало. Чаще всего такая ситуация проявляется через генерацию ABAP-дампов того или иного типа. Поэтому тут так же рекомендация - увеличить размеры областей памяти Page Area и Extended Memory. Размер Roll Area пока можно не менять. 

Согласно документации рекомендации по увеличению обоснованы уже при достижении 85% от максимального объёма областей. Помните: действовать проактивно, а не реактивно.

Extended Memory хранится только в оперативной памяти, а Page Area состоит из области в памяти плюс файл на диске. Сначала используется область памяти, а при достижении предела  данные записываются в файл на диске.

Таким образом, мои рекомендации по новым значениям параметров для общих областей памяти представлены в следующей таблице (рис. 10).

Рис. 10. Рекомендации по настройке областей памяти SAP инстанции.

Это лишь первый шаг настройки. После применения параметров, необходимо дать системе поработать, как я уже писал, пару недель. А далее провести анализ использования буферов и областей памяти в той же ST02. И если это необходимо, рассчитать и запланировать следующий шаг настройки.

Текущий объём общей памяти, сконфигурированной для SAP инстанции, составляет примерно 7 Гб ( если прибавить сюда память для рабочих процессов) (рис. 11). Напоминаю, что просмотреть это можно, перейдя в транзакции ST02 -> "Detail Analysis Menu" -> "Storage".

Рис. 11. Общая память, используемая SAP инстанцией.

После применения параметров этот объём увеличится примерно на 5 Гб. Что в текущей системе приемлемо - оперативной памяти сервера достаточно.

Увеличивать параметры следует аккуратно, не спеша. Общие рекомендации следующие:

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

В данном случае я составил рекомендации. Теперь дело за коллегой. Необходимо аккуратно применил новые параметры к SAP системе. При изменении параметров обязательно понадобится перезагрузка SAP инстанции. 

В продолжении можно прочитать про результаты тюнинга и новые рекомендации по тюнингу.

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