С наступающим Новым Годом!

Друзья, хочу поблагодарить вас за то, что всё это время вы были со мной. 

Без ваших комментариев, исправлений, участия в голосованиях и прежде всего чтения моих постов, я не смог бы так долго продержаться. :) И всё это не смотря на то, что пишу я то пусто, то густо. :) Спасибо вам.

Хочу поздравить вас всех с наступающим Новым Годом!

Надеюсь, что не смотря на санкции и импортозамещение, уходящий год был для вас добрым и достаточно щедрым: работы, проектов и задач всем было в самый раз, а личный бюджет не пострадал. Я в свою очередь, всегда готов помочь советом или поделиться информацией, если у кого возникнут проблемы. Адрес мой всем известен - shibolov@gmail.com.

В 2016 году хочу пожелать вам: 

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

Пусть следующий год будет приятным на сюрпризы и возможности. 

Как говорили Древние: "Поспешай медленно". Как говорили наши предки: "Тише едешь, дальше будешь". А я бы сказал: "Не спешите, но и не останавливайтесь". Верьте в себя, растите, развивайтесь. Пусть медленно, но каждый день.

Всем удачи!  

P.S. Спасибо за ваш голос. :) Я среди лучших авторов на SAPLand портале.

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

SAP буферизация: общие сведения

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

Рис. 1. SAP буферы.

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

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

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

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

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

Рис.2. SAP буферы с описанием.

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

Рис. 3. Основной экран транзакции ST02.

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

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

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

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

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

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

• коэффициент попадания (hit ratio), который показывает эффективность работы буфера,
• вытеснения из буфера (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.

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

SAPLand: голосование за лучших авторов

Как я уже писал, мои статьи и посты можно найти не только в этом блоге, но и на SAPLand портале.

Причем по техническим причинам портала, у меня там произошло раздвоение:

• я выкладываю статьи,
• я веду свою авторскую колонку.

Статьи там размещаются безвозмездно, то есть даром. :) 

Но в этом году, набрав солидное, для российского рынка, количество авторов и контента, владельцы портала решили провести голосование среди авторов и "наградить" лучших из лучших. :)

Если вы читаете мой блог и вам нравятся мои посты и статьи, то можете проголосовать за меня на портале.

Ссылка на голосование тут. Я, как уже упоминал, есть там в виде двух личностей: 8-ой и 15-й во внутреннем рейтинге авторов портала.

Для участия в голосовании необходимо зарегистрироваться на портале. У каждого читателя есть 3 голоса, которые вы можете отдать не только за меня, но и за кого угодно.

Спасибо, что читаете, комментируете и голосуете. :)

P.S. Меня объединили в одного - 5-е место. :)

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

Размер области подкачки в Linux: рекомендации

Операционная система для работающих приложений предоставляет память в рамках границ виртуальной памяти, которая, как я уже упоминал, представляет собой сумму оперативной памяти (ОЗУ, физическая память) и области подкачки.

Рекомендации для операционной системы MS Windows я описывал в этом посте.

В Linux данная область называется swap-space. Страницы памяти, которые давно не использовались (механизм LRU), выгружаются в область подкачки. Данный процесс называется "swap-out". Операция восстановления страниц в память, если они требуются процессу, называется "swap-in". Причем, для экономии операций записи на диск, восстановленные страницы не удаляются сразу из swap, а сохраняются, на случай, если в будущем потребуется их запись в swap, а страницы не изменились. В данном случае, реальной операции записи не происходит.

Когда сервера имели небольшой объем памяти, рекомендация по поводу размера области подкачки была простая = 3*(размер оперативной памяти). Но при объемах основной памяти больших, чем 24 Гб, следование данной рекомендации приведёт к очень большим размерам swap области, что в свою очередь приведёт к деградации общей производительности. Так же стоит учесть тот факт, что современные сервера переходят на использование SSD дисков, а они обладают меньшим размером, чем классические HDD, что приводит к невозможности создавать большие swap области на них.

Поэтому SAP для больших объемов оперативной памяти приводит нелинейные рекомендации для размеров swap-space (рис. 1).

Рис. 1. Рекомендации для swap области.

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

Подробности в SAP note # 1597355 - Swap-space recommendation for Linux.

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

Обновление SAP системы с помощью Software Update Manager 1.0

Когда SAP системы были большими простыми, когда была только ABAP часть системы, а слова "Java" и "SAP" никто и не думал произносить вместе, администратор обновлял систему поэтапно, не спеша, смакуя каждый шаг:

1. Сначала, обновлялась утилита SPAM/SAINT. Для этого использовалась транзакция SPAM.
2. Затем обновлялось ядро системы - SAP Kernel. 
3. Если было необходимо установить/обновить дополнения (Add-on), то использовалась транзакция SAINT.
4. Ну и в конце, с помощью транзакции SPAM, заряжались очереди пакетов поддержки для той или иной компоненты системы и, производился импорт.

Когда в ABAP части системы стало больше компонент, SAP начал выпускать (1-2 раза в полгода) стеки пакетов поддержки, или Support Package Stack (SPS). Это некий набор пакетов поддержки или, скорее, рекомендации по одновременному обновлению всех компонент системы с рекомендуемым уровнем SAP Kernel. Данный механизм облегчил скачивание, установку и отслеживание пакетов поддержки для всех компонент системы, при этом обеспечивая гарантию работы системы после обновления. Про это я писал тут.

Когда появилась JAVA часть системы, то обновление её так же легло на плечи администратора. Изначально, для этих целей использовалась утилита JSPM. 

Пример обновления системы на базе SAP NetWeaver 7.0 (ABAP+JAVA) я приводил в этом посте.

На данный момент существует утилита SAP Software Update Manager или просто SUM. Последняя версия утилиты 1.0 SP15. 

Одно из назначений SUM - это обновление ABAP и JAVA стеков системы. И если ABAP часть системы можно обновлять по-старинке, через транзакции SPAM/SAINT, то для обновления JAVA стека системы использование JSPM уже категорически не рекомендуется. Только SUM.

Для скачивания утилиты SUM 1.0 необходимо войти на SAP Support Portal по ссылке http://service.sap.com/sltoolset, там перейти по ссылке «Software Logistics Toolset 1.0» и в разделе «General Information» скачать последнюю версию (рис. 1). 

Рис. 1. Загрузка утилиты Software Update Manager.

Документация к утилите доступна там же, в разделе «Documentation → System Maintenance → Updating SAP Systems Using Software Update Manager 1.0 SP14». При скачивании необходимо выбрать нужную платформу (операционная система и база данных) (рис. 2).

Рис. 2. Загрузка документации по утилите Software Update Manager.

Скачивание утилиты, как и обычно, через SAP Download Manager.

Для установки или обновления (в случае присутствия старой версии) утилиты Software Update Manager 1.0 необходимо распаковать загруженный SAR-архив в директорию \usr\sap\<SAPSID>\SUM, выполнив команду вида (пример, MS Windows):

 > SAPCAR –xvf <SUM_archive>.SAR -R \usr\sap\<SAPSID> 

Учтите, утилита большая и время распаковки приличное. :)

Запуск осуществляется со стороны сервера и со стороны клиента. Серверная часть активируется через запуск из под пользователя Administrator (для MS Windows) исполняемого файла "\usr\sap\<SAPSID>\SUM\STARTUP.BAT" (рис. 3).

Рис. 3. Старт серверной части утилиты SUM 1.0.

Клиентская часть представляет собой Java-приложение (рис. 4), которое запускается через браузер, по URL вида:

http://<server_host>:4329

Рис. 4. Пример экрана утилиты SUM 1.0.

Основные требования:

• так как при работе Software Update Manager используется SAP Host Agent, то его необходимо обновить вручную. Подробности можно найти тут.
• все части SAP системы должны быть запущены.

Полезные SAP ноты по утилите:

• SAP note # 2084104 - Central Note - Software Update Manager 1.0 SP14,
• SAP note # 2115547 - Oracle: Add. Information - Software Update Manager 1.0 SP14.

Мои ощущения от использования утилиты противоречивые. Я как, старый солдат, не знающий слов любви (с), люблю контролировать все этапы процесса. А здесь, по сути, за работой утилиты происходит тоже самое, что и при по-этапном обновлении. Единственное нововведение: создание клона табличного пространства с программами (PSAPSR3XXX) и импорт обновлений в него, с последующим переключением на него, как на основное. Таким образом, снижается время недоступности (down-time) системы, но вырастают требования к месту на жестком диске.

Ну и напоследок, пример обновления системы SAP Solution Manager 7.1 на платформе MS Windows/Oracle с SPS11 до SPS14 с использованием Software Update Manager 1.0 SP14. Детальная инструкция объемом 41 страница, в которой описана процедура обновления вышеуказанной системы (ABAP+JAVA) с начала и до конца:

1. Скачивание необходимых пакетов поддержки, утилит, документации.
2. Обновление SAP Host Agent, Software Update Manager 1.0 SP14.
3. Обновление CR Content и модели для SLD.
4. Прохождение всех этапов обновления ABAP+JAVA стеков системы с решением проблем.
5. Шаги, необходимые после обновления (удаление старого табличного пространства).

Скачать можно по этой ссылке (zip-архив, 3881 Кб).

Так же обновил страницу, где собраны все мои личные инструкции.

Если найдете неточности или будут проблемы со скачиванием, пожалуйста, дайте знать письмом на адрес shibolov@gmail.com.

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

Материалы SAP курсов: новый ресурс

На странице с материалами SAP курсов появилась ссылка на новый ресурс. Там есть курсы по администрированию SAP систем, BW и Solution Manager. Не знаю, сколько проживет ресурс, это личный блог Евгения Губского.

P.S. Ресурс долго не прожил. Евгений, к сожалению, закрыл свой блог.

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

Опрос: дистрибутив Linux и версия ORACLE

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

Наибольшую популярность среди операционных систем получил Linux, на втором месте AIX. В меньшинстве оказались OS/390, OS/400 от IBM. Сдал позиции и Solaris, некогда очень популярная платформа. Кстати, по операционным системам результаты опроса идут в разрез с результатами статистики, что я выкладывал тут. Что на это повлияло, я не знаю. Может быть изменения в тренде, может быть ограниченность нашей выборки, а может быть не равнозначность данных: в прошлой статистике были данные о приобретенных в компании SAP инсталляциях. А сейчас я просил указывать платформы для "боевых систем".

Среди баз данных по прежнему лидирует ORACLE, до сих пор с большим отрывом. Посмотрим, как будет развиваться ситуация далее. Претендентов на лидерство два: DB2 LUW и SAP HANA Database.

По версиям системы всё получилось более или менее предсказуемо - у большинства относительно свежие версии: SAP NetWeaver 7.4, 7.3, да и версия 7.0 еще не старая. :)

На основе полученных от вас данных (еще раз спасибо за участие), хотел бы провести в вдогонку еще два опроса: посмотреть на наиболее популярную на данный момент версию ORACLE и дистрибутив Linux. Просьба указывать те же системы, что и в прошлом опросе: системы из основных ландшафтов (не песочницы, игровые или "для себя").

В опросе участвовало 23 человека. Всем спасибо.

Результаты:

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

Организация памяти в SAP AS ABAP. Заключение

В опубликованных мною 9 постах про организацию памяти в SAP системе (ABAP части) я осветил всё, что планировал на данный момент:

• Организация памяти в SAP AS ABAP - I - что такое виртуальная память в SAP; shared и local memory, как основные части в организации памяти в SAP AS ABAP.
• Организация памяти в SAP AS ABAP - II - механизм выделения памяти диалоговым и не-диалоговым рабочим процессам.
• Организация памяти в SAP AS ABAP - III - основные параметры настройки памяти в SAP системе.
• Организация памяти в SAP AS ABAP - IV - как с помощью транзакций ST02 и SM04 проводить мониторинг областей памяти в SAP AS ABAP.
• Рабочие процессы в PRIV режиме - что такое PRIV режим рабочего процесса, чем этот режим опасен для производительности системы и как это контролировать. 
• ZAMM: упрощенная конфигурация памяти в MS Windows - что такое «Zero Administration Memory Management», как это работает на платформе MS Windows.
• Особенности конфигурации памяти в SAP AS ABAP на Linux - две системы управления памяти в Linux - MAP implementation и STD implementation; когда возможна активация «Zero Administration Memory Management» на данной платформе.
• SAP NetWeaver 7.4: особенности конфигурации памяти - что нового в конфигурации памяти в системах SAP NetWeaver 7.40 и выше: ZAMM для Unix систем, упразднение Roll memory и другое.
• Какого размера область подкачки необходима для SAP системы? - как рассчитать начальный размер виртуальной памяти и swap области для SAP системы, утилита memlimits, которая позволяет проверить выделение памяти для одного процесса на уровне операционной системы.

Осталась упомянуть ещё пару моментов. 

Немного повторюсь, но основные цели при конфигурации и рекомендации следующие:

• В качестве основной области памяти для SAP системы необходимо стремиться использовать SAP Extended Memory, уменьшая долю SAP Roll memory (для систем < SAP NetWeaver 7.40). Необходимо так же избегать использования Heap Memory диалоговыми рабочими процессами и перехода их в PRIV режим. Это позволит рабочим процессам быстро переключать контексты пользователей и поддерживать общую производительность системы при работе большого количества пользователей на высоком уровне.
• При выборе архитектуры сервера следует отдавать предпочтение 64-битной. Причины я указывал в первом посте.
• На сервере должна быть сконфигурирована swap область (paging file) достаточного объема. SAP рекомендует использовать размер = 3 * (размер оперативной памяти). Для серверов с большим количеством оперативной памяти следует делать свою поправку, так как цифра по формуле получается очень большой. Минимальные цифры: 32-бита - 3,5 Гб; 64-бита - 20 Гб. Подробности тут. 
• Необходимо стремиться в качестве расположения виртуальной памяти SAP использовать оперативную память сервера, а не область подкачки (swap). Основная рекомендация - виртуальная память SAP должна быть меньше, чем 150 % от основной памяти сервера (в идеале, меньше, чем размер физической памяти). Конечно же, не стоит забывать про память, которая выделяется инстанции базы данных (в случае работы центральной инстанции и инстанции базы данных на одном сервере) или другим приложениям.
• Величина максимального использования Roll area (поле MaxUse) должна быть не больше 80 % от размера буфера Roll area (In Mem). То есть использование файла на диске для Roll area не рекомендуется.
• Величина максимального использования SAP Extended memory (поле MaxUse) должно быть не больше 80 % от сконфигурированного размера (In Mem). Всем активным пользователям должно с запасом хватать данного вида памяти.
• Рекомендуется использование «Zero Administration Memory Management» (ZAMM), как наиболее оптимального метода использования памяти системой SAP. Особенно, если вы не сильны в конфигурации памяти, а ваша платформа-версия системы позволяет активировать это.
• С регулярной периодичностью (не реже 1 раза в месяц) проводить мониторинг использования памяти всеми инстанциями системы, используя транзакцию ST02 и другие инструменты.
• При изменении конфигурации оборудования или количества рабочих процессов, пользователей, инстанций, компонентов и модулей системы производить своевременную корректировку настроек памяти SAP.
• Отслеживать дампы системы (транзакция ST22), которые возникают в следствии не оптимальной настройки системы памяти в SAP. Это могут быть дампы вида: STORAGE_PARAMETERS_WRONG_SET, SYSTEM_ROLL_IN_ERROR, TSV_TNEW_BLOCKS_NO_ROLL_MEMORY, SYSTEM_NO_ROLL, SET_PARAMETER_MEMORY_OVERFLOW и т.п.

В составе SAP Kernel есть утилита sappfpar, которая позволяет провести тестирование параметров памяти, установленных в профиле инстанции. 

Запуск производить из под пользователя <sid>adm, формат команды следующий:

 # sappfpar check pf=/usr/sap/<SID>/SYS/profile/<Instance_profile> nr=<system_number> name=<SID> 

В конце экрана с результатами утилита выведет информацию об ошибках и предупреждениях (рис. 1). В данном примере ошибок нет.

Рис. 1. Проверка профиля инстанции с помощью утилиты sappfpar.

Данную проверку можно запустить из транзакции RZ10, выбрав пункт меню "Профиль -> Проверить" (рис. 2). Данная проверка запускается автоматически при сохранении профиля после изменений.

Рис. 2. Результаты проверки профиля инстанции в транзакции RZ10.

У этой утилиты есть другая замечательная функция, которую можно использовать в Unix системах. В посте про мониторинг памяти я описывал как подсчитать общее количество виртуальной памяти в SAP. Утилита sappfpar делает похожие вычисления. В строке "Total, minimum requirement" она выдает минимальные требования к виртуальной памяти со стороны SAP, а в строке "Total, worst case requirement" - максимальное количество, которое может быть занято данной инстанцией (рис. 3 и 4).

Рис. 3. Пример результатов работы утилиты sappfpar.

Рис. 4. Пример результатов работы утилиты sappfpar.

Согласуясь с последней цифрой из результатов работы утилиты, необходимо обеспечить систему достаточным количеством области подкачки (swap). Подробности тут и тут.

По мере раскрытия темы я уже привёл много SAP нот, но есть еще несколько на данную тему:

• SAP note # 103747 - Performance: Parameter recommendations as of Release 4.0,
• SAP note # 146289 - Parameter Recommendations for 64-Bit SAP Kernel,
• SAP note # 117907 - Display of SAP Memory usage in SM04 and ST02,
• SAP note # 133909 - Maximum value for PG_MAXFS, PG_SHM, ROLL_MAXFS, ROLL_SHM,
• SAP note # 425207 - SAP memory management, current parameter ranges,
• SAP note # 548845 - Internal modes uses more than 2 GB,
• SAP note # 835474 - More than 32 GB extended memory.

Данная тема освещается в курсе SAP "ADM315 - Workload Analysis AS ABAP" (Unit 3). Так же можно заглянуть в книгу Thomas Schneider "SAP Performance Optimization Guide".

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

Какого размера область подкачки необходима для SAP системы?

Как я уже ни раз упоминал, на уровне операционной системы существует понятие виртуальной памяти. Данная память состоит из физической памяти сервера и области подкачки. Область подкачки в разных операционных системах представляет собой либо файл, либо область на жестком диске. В операционных системах семейства MS Windows эта область называется файлом подкачки или paging file и представляет собой один или несколько файлов на жестких дисках сервера (рис. 1).

Рис. 1. Paging file в MS Windows.

В операционных системах семейства Unix данная область имеет название swap (swap space) и, может быть представлена как файловая система или как диск (раздел) целиком (рис. 2).

Рис. 2. Пример вывода команды swapinfo в ОС HP-UX.

Со стороны системы SAP есть определенные требования к размеру области подкачки. При недостаточном размере система может не запуститься, так как не сможет разместить все свои области в виртуальной памяти операционной системы, или могут возникнуть проблемы в работе программы установки системы (SAPINST, SAP Software Provisioning Manager).

В эпоху 32-битных серверных архитектур и небольших объемов физической памяти, требование было простое - 3*(размер физической памяти), но минимум 3,5 Гб.

Сейчас все поменялось. При объеме физической памяти в 128 Гб, выделять для swap области 384 Гб нерационально и бессмысленно. К тому же, кардинально изменился состав SAP систем - инстанция базы данных, ABAP инстанция, которая может включать в себя PAS (CI) и AAS (DI), Java инстанция (SCS инстанция, Java инстанция с разным количеством Server processes), SAP агенты (SMD и SAP Host Agent) и т.д. Каждая компонента системы имеет свои требования к виртуальной памяти.

Как рассчитать общие требования при установке той или иной SAP системы?

Ну во-первых, требования к памяти есть в Installation Guide для каждой системы. Конечно же, требования там начальные, но и они позволяют запустить систему и работать с минимальной нагрузкой со стороны пользователей.
Во-вторых, на этой странице SAP Community Network есть ссылка на документ, в котором проведена попытка свести требования к памяти со стороны различных компонент SAP системы в таблицы. А к SAP note # 1518419 - Page file and virtual memory required by the SAP system прикреплена Excel-табличка, которая позволяет произвести подсчет требований к виртуальной памяти операционной системы. Введя размер физической памяти сервера, можно получить требования к размеру области подкачки (рис. 3).

Рис. 3. Пример расчета paging file для SAP системы.

Данная нота и расчёт созданы для операционных систем семейства MS Windows, но я думаю, что для Unix систем, в качестве точки отсчета, это то же можно смело использовать.

Для продуктивной системы, конечно же, необходимо проведение процедуры Hardware Sizing совместно с производителем оборудования.

Также в составе SAP Kernel есть утилита memlimits, которая позволяет протестировать выделение памяти в данной операционной системе. Программу на 64-битных платформах необходимо запускать с ключом -l, указав после него размер запрашиваемой памяти в Мб (рис. 4):

 # memlimits -l 20000 

Рис. 4. Пример вывода команды memlimits -l 20000 в HP-UX.

Первая строка в результатах "Maximum heap size per process" показывает, сколько памяти может быть занято локально одним процессом - Local work processes memory.
"Maximum protectable size (mprotect)" показывает лимит для SAP Extended Memory.
"Maximum address space per process" - лимит памяти, которая может быть выделена процессу в сумме.

На операционной системе MS Windows данная утилита так же доступна, но картина с результатами несколько иная (рис. 5).

Рис. 5. Пример вывода команды memlimits -l 20000 в MS Windows.

Здесь важной является первая строка результата - "Maximum heap size per process", которая, как и в Unix, показывает сколько памяти может быть выделено одному рабочему процессу в системе.

Данной утилитой так же можно проверить максимальное количество доступной виртуальной памяти, указав после ключа -l большое число (например, 120000) и проанализировав результаты в последней строке (рис. 6).

Рис. 6. Пример вывода команды memlimits -l 120000 в HP-UX.

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

Подробности можно найти тут или в справке к программе по ключу -h:

 # memlimits -h 

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

SAP NetWeaver 7.4: особенности конфигурации памяти

Начиная с SAP Kernel 7.40 (ядро, которое поставляется в паре с системой SAP NetWeaver 7.4), в организации памяти в SAP AS ABAP были произведены два крупных нововведения:

• упразднение SAP Roll memory,
• введение Zero Administration Memory Management (ZAMM) для Unix систем. 

Как я уже упоминал в этом и этом постах, SAP Roll Memory состоит из SAP Roll buffer и SAP Roll file и служит для хранения контекста пользователя (имя, полномочия, значения по умолчанию и т.д.). Схемы выделения памяти для диалогового и не-диалогового процессов (в Unix системах), описанные мной тут, выглядят следующим образом:

• диалоговый процесс: Roll memory (1) -> Extended memory -> Roll memory (2) -> Heap memory.
• не-диалоговый процесс: Roll memory -> Heap memory -> Extended memory.

В SAP NetWeaver 7.4 схема выделения памяти значительно упростилась:

• диалоговый рабочий процесс: Extended memory -> Heap memory.
• не-диалоговый рабочий процесс: Heap memory -> Extended memory.

Описание схем можно найти в SAP note # 941735 - SAP memory management system for 64-bit Linux systems. 

Таким образом, SAP параметры ztta/roll_area, ztta/roll_first, rdisp/ROLL_MAXFS и rdisp/ROLL_SHM были удалены (источник). Напомню, что все параметры я перечислил в этом посте.

Все данные, которые раньше хранились в SAP Roll memory, теперь хранятся в Extended Memory.

В транзакции ST02 строка с SAP Roll memory присутствует в виде рудимента (рис. 1 и 2).

Рис. 1. Основной экран транзакции ST02 в системе SAP NetWeaver 7.4.

Рис. 2. Список SAP параметров для настройки памяти в SAP AS ABAP.

В системе появился отчет RSMEMORY (запуск через транзакцию SA38/SE38) (рис. 3), который позволяет настраивать схемы выделения памяти для диалоговых и не-диалоговых рабочих процессов (схема выделения будет действовать только для текущей инстанции и только до перезапуска). Подробности тут.

Рис. 3. Отчет RSMEMORY.

Вторая большая особенность системы на базе SAP Kernel 7.4x это введение ZAMM для Unix систем. До этого момента ZAMM был доступен для систем MS Windows (я описывал тут) и для 32-х битных Linux систем (подробности тут). 

ZAMM, в данном случае, настраивается аналогичным образом. Меняем значение параметра PHYS_MEMSIZE, если необходимо (по-умолчанию, равен размеру физической памяти, установленной на сервере)(рис. 4). 

Рис. 4. Параметр PHYS_MEMSIZE.

В отличие от систем на платформе MS Windows, Extended Memory в Unix статична: 

em/max_size_MB = em/initial_size_MB = 70 % от PHYS_MEMSIZE (рис. 5 и 6).

Рис. 5. SAP параметр em/initial_size_MB.

Рис. 6. SAP параметр em/max_size_MB.

Формулы для всех параметров, значения которых рассчитываются в рамках ZAMM, можно найти в SAP note # 2085980 - New features in memory management as of Kernel Release 7.40.

Стоит отметить еще пару моментов. Как я упоминал в этом посте, внутри Extended Memory выделяют область, которая называется Extended Global Memory (сокращенно EG). Данная область определяется параметром em/global_area_MB и составляет около 5-10 % от Extended Memory (SAP note # 1514752 - Extended Global Memory configuration). Начиная с SAP Kernel 7.40, в Extended Global Memory перенесли Table Buffer, который хранит записи таблиц на уровне сервера приложений SAP. И все это хранится в Extended Memory (рис. 7).

Рис. 7. Содержимое Extended Memory в SAP AS ABAP.

Таким образом, в новой версии SAP NetWeaver Extended Memory содержит больше областей, чем в предыдущих версиях. Это означает, что при равных значениях параметра em/initial_size_MB в ранних релизах и в SAP NetWeaver 7.4, в последней может наблюдаться недостаток данной памяти для работы пользователей. Особенно следует учитывать данную деталь в случае обновления системы до версии SAP NetWeaver 7.4 с предыдущих версий. На основном экране транзакции ST02 перенос Table Buffer в EG легко прослеживается (рис. 1).

Подробности в SAP note # 2148571 - Explanation for higher Extended Memory (EM) and Extended Global Memory (EG) consumption after upgrade to SAP Kernel 7.4x. 

Начиная с SAP NetWeaver 7.40 SPS08 (SAP Kernel 7.42), появляется новый вид памяти - PROC/Heap Memory, который принадлежит рабочим процессам (то есть является локальным), но не содержит контекст пользователя, как Heap Memory. Лимит, определяющий максимальное количество данной памяти для всех рабочих процессов, определяется параметром em/proc_max_size_MB. Значение по-умолчанию равно 0, что означает без ограничений. При введении ограничения рекомендуется выделять по 100 Мб на рабочий процесс. 

Подробности в SAP note # 2019744 - How to limit overall swap space consumption of the ABAP Server in NW 7.40 .

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

Особенности конфигурации памяти в SAP AS ABAP на Linux

В прошлом посте я писал про особенности конфигурации памяти в ABAP инстанции SAP системы, работающей в среде операционной системе MS Windows. Особый упор был сделан на механизм упрощенной конфигурации или ZAMM. В этот раз рассмотрим среду Linux.

В операционной системе Linux доступны две разные системы управления памятью. Переключение производится посредством SAP параметра es/implementation:

• MAP implementation (es/implementation = map).
• STD implementation (es/implementation = std).

MAP implementation - в данном случае, только активный в текущий момент времени контекст пользователя виден в адресном пространстве рабочего процесса. Использование оптимально в 32-битной версии операционной системы. Возможно использование для систем на базе SAP Kernel 4.5B (уровень патча 731) и выше. Для SAP Kernel версий от 6.20 до 7.00 является системой по-умолчанию (es/implementation = map).

Для использования необходимо Linux ядро 2.4 и TMPFS, смонтированная под /dev/shm, так как SAP Extended Memory хранится в TMPFS.

Стоит отметить, что в данном случае, возможна активация Zero Administration Memory Management (ZAMM), как в операционной системе MS Windows. 

Как и в MS Windows, активируется через параметр PHYS_MEMSIZE, который устанавливается в зависимости от размера оперативной (физической) памяти. Возможна установка в процентном отношении ('100%', '50%', '25%'). В данном случае, сообщение об ошибке ('не цифровое значение') в RZ10 можно игнорировать. Большая часть параметров должна быть удалена из профиля, их установка будет выполнена в автоматическом режиме, в зависимости от параметра PHYS_MEMSIZE (рис. 1).

Рис. 1. Параметры SAP профиля, которые устанавливаются в рамках ZAMM.

Данную схему управления можно использовать и в 64-битной операционной системе, но это не рекомендуется. 

Подробности в SAP note # 386605 - SAP Memory Management for Linux (32-bit).

В ноте, помимо вышеуказанной информации, описано, как корректно монтировать TMPFS, в поддерживаемых SAP AG, версиях Linux.

STD implementation - в данном случае, используется схема управления памятью, как в Unix системах: все контексты пользователей видны в адресном пространстве одновременно. Начиная с SAP Kernel 7.10, в 64-битных Linux системах STD implementation активировано по-умолчанию. 

При STD implementation значение параметров SAP идентично классической Unix схеме. Про это я писал в посте - Организация памяти в SAP AS ABAP - III.

В данном контексте важными являются следующие параметры операционной системы Linux (настройка в файле /etc/sysctl.conf):

• kernel.shmmax - не рекомендуется изменять значение, которое установлено по-умолчанию, так как оно уже достаточного размера.
• kernel.shmall - не рекомендуется изменять значение, которое установлено по-умолчанию, так как оно уже достаточного размера.
• TMPFS - хотя уже не используется для хранения SAP Extended Memory, но SAP рекомендует использовать значение равное 75 % от виртуальной памяти операционной системы (ОЗУ + swap).

Подробности в SAP note # 941735 - SAP memory management system for 64-bit Linux systems.

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

P.S. Коллеги, у кого системы работают на AIX (до SAP NetWeaver 7.40), помогите материалом для следующего поста: скриншоты, список нот, личные заметки. Знаю, что там есть своя специфика в работе механизма управления памятью, но сам никогда с системами на этой операционной системе не сталкивался. Спасибо. :)

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

SAP NetWeaver AS ABAP 7.03 SP4 64-bit Trial

MiniSAP(старое название) - это SAP система, созданная прежде всего для разработчиков на ABAP, распространяется компанией SAP бесплатно, как Trial версия. Я про это писал в этом и этом постах.

Сегодня я хочу написать, как установить систему SAP NetWeaver AS ABAP 7.03 SP4 64-bit Trial. На данный момент это последняя версия ABAP Trial системы, которую можно скачать.

Доступна она, как и две предыдущие, по этой ссылке (необходима бесплатная регистрация на SAP SCN портале).

Требования к системе подросли, так как это уже 64-битная система:

• Windows 7 Professional или Windows Server 2008 (64-бит).
• минимум 2 Гб ОЗУ (желательно 4 Гб или больше),
• файл подкачки 16 - 24 Гб (программа установки просит именно 24 Гб),
• Intel Pentium III 1.1 GHz или выше,
• 45 Гб на HDD (36 Гб занимает система с базой данных после установки), файловая система NTFS,
• отсутствие установленной SAP системы и MaxDB инстанции.

Документацию по установке и использованию искать в файле start.htm в архиве с дистрибутивом.

Я устанавливал в виртуальную машину с 3 Гб оперативной памяти. Жесткого диска размером 80 Гб мне хватило (после установки свободно осталось всего 6 Гб). При этом paging file настроил размером 16 Гб.

В качестве операционной системы выбрал MS Windows 2008 64-bit ENG.

ZAMM: упрощенная конфигурация памяти в MS Windows

В этом посте я приводил основные параметры инстанции SAP AS ABAP, которые отвечают за конфигурацию памяти.

Для операционной системы MS Windows, начиная с систем основанных на SAP BASIS 4.0, доступна упрощенная конфигурация памяти или «Zero Administration Memory Management» (сокращенно ZAMM). Целью данного нововведения было сокращение количества параметров, необходимых для конфигурации памяти, и, соответствующее, упрощение процедуры конфигурации оной.

ZAMM активируется через установку параметра PHYS_MEMSIZE.

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

Рис. 1. Значение параметра PHYS_MEMSIZE, равное размеру ОЗУ.

ZAMM базируется на динамическом изменении SAP Extended Memory, которая изменяется от размера указанного в параметре PHYS_MEMSIZE до лимита, указанного в параметре em/max_size_MB. Или пока выделение не остановит предел виртуальной памяти операционной системы MS Windows. Как я уже говорил, виртуальная память операционной системы это сумма оперативной памяти (физической памяти) сервера и файла подкачки (paging file или swap space). По-умолчанию, значения параметра em/max_size_MB - 20 000 Мб (32-битная архитектура), 100 000 Мб (64-битная архитектура) (рис. 2). В данном случае, очень важным является размер paging file, он должен быть достаточного размера. Рекомендации я приводил тут.

Рис. 2. Значение параметра em/max_size_MB.

Все остальные параметры, о которых я писал тут, вычисляются автоматически, устанавливать их вручную необходимости нет, хотя, это и возможно в рамках активной ZAMM.

SAP Heap memory имеет, в данном случае, меньшее значение, так как в MS Windows диалоговые и не-диалоговые рабочие процессы сначала используют Extended memory, а она, при использовании ZAMM, динамически расширяется.

SAP параметр ztta/roll_extension (размер квоты для одного пользователя в Extended memory),  установленный в значение 2 000 000 000, деактивируется, и используется значение параметра em/address_space_MB (по-умолчанию, 512 Мб для 32-бит и 4 Гб или 8 Гб для 64-бит) (рис. 3).

Рис. 3. Значение параметра em/address_space_MB.

В моем примере, настройка памяти, в рамках упрощенной конфигурации памяти (ZAMM) и не установленных вручную параметрах для памяти, выглядит так, как на рисунке 4.

Рис. 4. Конфигурация памяти в SAP с помощью ZAMM.

Подробности по ZAMM для Windows и примеры формул автоматического расчета остальных параметров памяти для разных версий SAP kernel  можно найти в SAP Note 88416 - Zero administration memory management for the ABAP server.

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

Опрос: статистика по SAP платформам

В 2011 году я выкладывал статистические данные по количеству инсталляций SAP систем на те или иные платформы (операционная система и СУБД) в России. Данные эти были старые и  неполные (а сейчас и подавно).

А недавно я подумал, а почему бы нам не провести свой опрос.

Итак, прошу. Отметьте какие операционные системы, СУБД и версии SAP_BASIS (SAP NetWeaver) используются у вас на проектах. Интересуют больше всего продуктивные системы (игровые, песочницы просьба не включать). Ошибки с прошлым опросом учёл, в данном можно отметить несколько вариантов для каждого опроса.

Если выбрали пункт другое, напиши в комментарии что именно используется.

Спасибо. Результаты опроса будут после 10 ноября.

Обновление: в итоге, в голосовании участвовало 40 человек. Всем спасибо. Результаты разместил.


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

Рабочие процессы в PRIV режиме

Как я описывал во второй части моего рассказа об организации памяти в SAP AS ABAP, последовательность выделения памяти диалоговому рабочему процессу следующая:

1. Сначала для пользователя выделяется небольшой объем Roll area, который задается параметром ztta/roll_first (100-200 Кб).
2. Если размер контекста пользователя растет, то используется память Extended memory через указатели (pointers). 
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, то программа прерывается с дампом, сообщающем о нехватке памяти.

Таким образом, после того, как рабочий процесс использовал всю память, разрешенную квотами, в Roll area + Extended memory, ему выделяется память из области SAP Heap memory. С этого момента данный рабочий процесс переходит в привилегированный режим работы (PRIV mode) (рис. 1). Это означает, что данный диалоговый рабочий процесс будет закреплен за данным пользователем, то есть не будет выгружать его контекст (roll-out) до тех пор, пока пользователь не выполнит все шаги текущей транзакции.

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

Рабочий процесс в PRIV режиме работает хорошо, но скорость работы других пользователей, а, следовательно, и производительность всей системы в целом, снижается, так как мультиплексирование рабочих процессов для данного рабочего процесса не работает. Снижение производительности будет тем больше, чем больше рабочих процессов находится в PRIV режиме.

В SAP системе такие процессы отслеживаются в транзакции SM50 (рис. 2).

Рис. 2. Рабочий процесс в PRIV режиме в транзакции SM50.

Выполнив в транзакции SM04 пункт меню "Goto -> Memory", можно также обнаружить данного пользователя, который использует SAP Heap Memory (рис. 3).

Рис. 3. Транзакция SM04: мониторинг использования SAP Heap memory пользователями.

Войдя в транзакцию ST02, на основном экране можно наблюдать текущее использование SAP Heap memory (рис. 4).

Рис. 4. Текущее использование SAP Heap memory.

Нажав комбинацию кнопок "Detail analysis menu -> SAP memory -> Mode list", можно обнаружить режим данного пользователя и информацию об использовании им памяти. Отсутствие пометки "X" в поле "Attchd" означает, что рабочий процесс в данный момент не выполняет никакой задачи от пользователя, но содержит его контекст и простаивает в PRIV режиме (рис. 5).

Рис. 5. Список режимов пользователей с информацией об использовании памяти.

При выделении рабочему процессу SAP Heap memory больше чем задано квотой (параметр abap/heaplimit), рабочий процесс отмечается для будущего рестарта на уровне операционной системы. В данном случае после окончания транзакции рабочий процесс выполняет рестарт. Данный процесс необходим для полного и корректного освобождения локальной памяти, занимаемой рабочим процессом (рис. 6). Особенно это актуально для Unix-like операционных систем.

Рис. 6. Рестарт рабочего процесса после PRIV режима.

Рабочие процессы, выполнившие рестарт по данной причине, не отмечаются флагом "Err" в транзакции SM50, но оставляют запись об этом в журналах рабочих процессов (dev_wX).

В системе необходимо избегать ситуаций перехода рабочих процессов в PRIV режим, прежде всего, выделяя достаточное количество Extended memory.

Так же есть дополнительные параметры, позволяющие контролировать ситуацию:

• rdisp/wppriv_max_no (по-умолчанию, "(количество диалоговых рабочих процессов)-5" или "1") - определяет максимальное количество процессов в PRIV режиме, 
• rdisp/max_priv_time (по-умолчанию, "600") - устанавливает ограничение по времени работы рабочего процесса в PRIV режиме. 

Если количество рабочих процессов, работающих в PRIV режиме, превышает количество, указанное в параметре rdisp/wppriv_max_no, и время работы рабочего процесса в PRIV режиме превышает значение, указанное в параметре rdisp/max_priv_time, то происходит сброс самой долго-работающей транзакции в рабочем процессе в PRIV режиме.

Подробности в SAP Note 79435: Automatic resetting from PRIV mode.

Данный механизм не действует на не-диалоговые рабочие процессы. Хотя, как я уже и описывал, они в первую очередь используют Heap memory, оставляя Extended memory для диалоговых рабочих процессов.



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