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

В прошлом посте я описал проблему, с которой ко мне обратился коллега. По словам коллеги, SAP система работала медленно, а многие рабочие процессы AS ABAP инстанции переходили в PRIV режим работы. Анализ показал, что размеры буферов и общих областей памяти SAP инстанции нуждаются в корректировке. Мною были составлены рекомендации, которые были успешно применены к системе. И в этом посте мы проанализируем результаты тюнинга. 

Итак, с помощью SAP параметров были увеличены некоторые области памяти и буферы инстанции. В результате этого общая виртуальная память SAP инстанции выросла на 5,5 Гб (рис. 1 и 2).

Рис. 1. Виртуальная память SAP инстанции до корректировки. 

Рис. 2. Виртуальная память SAP инстанции после корректировки.

Но, как вы помните из прошлого поста, объём оперативной памяти сервера составляет 256 Гб, что вполне достаточно для увеличенного объёма памяти SAP инстанции. Поэтому и после увеличения аппетитов SAP инстанции swap область на сервере не используется (рис. 3). А значит  эффективность работы с памятью на уровне операционной системы не упала.

Рис. 3. Вывод команды top на сервере после корректировки.

Корректировки параметров были сделаны 14 апреля. После этого система проработала чуть больше недели. Основной экран транзакции ST02 на данный момент выглядит следующим образом (рис. 4). Инстанция перезагружалась 15 апреля, снимок экрана сделан 23 апреля (1).

Рис. 4. Основной экран транзакции ST02 после корректировки.

Какие выводы, глядя на этот экран, можно сделать:

1. Из Program Buffer (2) используется почти 800 Мб и на данный момент размера в 1 200 Мб достаточно. Ясно, что предыдущего размера в 300 Мб катастрофически не хватало. Параметры, отвечающие за этот буфер, пока корректировать нет необходимости.
2. Объёма CUA Buffer (2) системе до сих пор не хватает. Хотя количество swaps снизилось, но буфер надо бы увеличить ещё. Причём, обратите внимание, что не хватает именно объёма, а не максимального количества записей. Кто-то внимательный заметит, что я рекомендовал в прошлый раз размер буфера равный 6 000 Кб, а по факту он стоит 9 000 Кб. Дело в том, что по нему один раз уже были повторные корректировки: 15 апреля поднимали его размер ещё на 3 000 Кб. Поэтому изначальные изменения параметров были сделаны 14 апреля, а инстанция была повторно перезагружена 15 апреля, именно из-за CUA Buffer.
3. Размер Screen Buffer (2) требованиям системы удовлетворяет гораздо лучше, чем CUA. Можно было бы его не трогать. Но памяти на сервере много и размер буфера не большой, поэтому рекомендуется также немного увеличить и его. 
4. Пиковое использование области памяти Extended Memory (3) было зафиксировано на уровне 6 Гб. Из этого ясно, что предыдущего объёма в 4 Гб было недостаточно. Система с новыми значениями параметров проработала ещё мало. Но, так как рабочие процессы инстанции используют эту память в большом объёме и, памяти на сервере достаточно, я бы сразу порекомендовал ещё немного её увеличить. А после этого понаблюдать за системой на большем промежутке времени. 
5. Пиковое использование области Paging Area (3) за это время достигало более 400 Мб при размере области 256 + 256 = 512 Мб. В прошлый общий объём в 256 Мб, опять же, явно система упиралась. На втором шаге корректировки я бы рекомендовал увеличить ту часть этой области, что находится в оперативной памяти, соответственно увеличив общий объём.

Остальные области я бы пока не трогал. И даже буфер Tables: Generic Key, не смотря на наличие 2-х swaps за 8 дней работы. Как показывает практика, небольшое количество swaps при работе этого буфера будет почти всегда.

Напомню ещё раз: угадать с первого раза со 100% точностью оптимальный размер буферов и областей не получится. Обычно процесс настройки состоит из нескольких шагов. Мои рекомендации на данном шаге это необходимость изменить значения следующих параметров:

• rsdb/cua/buffersize = 12 000
• zcsa/presentation_buffer_area = 12 000 000
• em/initial_size_MB = 10 240
• rdisp/PG_SHM = 65 536
• rdisp/PG_MAXFS = 98 304

Ну и на последок, давайте посмотрим, а как изменилась производительность системы не по субъективным ощущениям, а по объективным данным - цифрам. 

Базовым показателем производительности системы является среднее время отклика системы. При диалоговом режиме работы пользователей этот параметр - это среднее время отклика системы на шаг диалога. Общее время, которое система обрабатывала диалоговые шаги в рабочих процессах типа DIA, делится на количество выполненных шагов. Получается среднее время выполнения одного шага диалога. 

Корректно настроенная SAP система собирает эту информацию на постоянной основе с помощью служебных фоновых заданий. И результаты собранной статистики можно посмотреть в транзакции ST03 (ST03N). 

Как я уже написал выше, параметры были скорректированы 14 апреля. Посмотрим среднее время отклика системы за следующие недельные периоды:

• 29.03.2021 - 04.04.2021 (рис. 5),
• 05.04.2021 - 11.04.2021 (рис. 6),
• 12.04.2021 - 18.04.2021 (рис. 7),
• 19.04.2021 - 25.04.2021 (эта неделя) (рис. 8).

Рис. 5. Показатели времени отклика системы за период до корректировки -1.

Рис. 6. Показатели времени отклика системы за период до корректировки - 2.

Рис. 7. Показатели времени отклика системы за период после корректировки - 1.

Рис. 8. Показатели времени отклика системы за период после корректировки - 2.

Такого результата не ожидал даже я. Среднее время реакции системы на шаг диалога сократилось с 3,4 - 4,4 секунды до 0,8 - 0,7 секунды. То есть, как минимум в 4 раза! Сокращение времени отклика произошло за счёт интервалов, когда выполнялась работа на центральном процессоре. То есть раньше вместо расчётов, система занималась борьбой за ресурсы памяти. 

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

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