26 ноября 2015 г.

Размер области подкачки в 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.

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


17 ноября 2015 г.

Обновление 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 системы должны быть запущены.

Мои ощущения от использования утилиты противоречивые. Я как, старый солдат, не знающий слов любви (с), люблю контролировать все этапы процесса. А здесь, по сути, за работой утилиты происходит тоже самое, что и при по-этапном обновлении. Единственное нововведение: создание клона табличного пространства с программами (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.

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


10 ноября 2015 г.

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


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

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

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


9 ноября 2015 г.

Опрос: дистрибутив 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 человека. Всем спасибо.

Результаты:




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


6 ноября 2015 г.

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

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

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

Немного повторюсь, но основные цели при конфигурации и рекомендации следующие:
  • В качестве основной области памяти для 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 "ADM315 - Workload Analysis AS ABAP" (Unit 3). Так же можно заглянуть в книгу Thomas Schneider "SAP Performance Optimization Guide".


2 ноября 2015 г.

Какого размера область подкачки необходима для 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 

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