Организация памяти в SAP AS ABAP - III

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

• Организация памяти в SAP AS ABAP - I - описаны виды памяти в SAP инстанции,
• Организация памяти в SAP AS ABAP - II - описаны схемы выделения памяти для диалоговых и не-диалоговых рабочих процессов в системе SAP.

Размеры всех областей памяти в SAP, про которые мы уже говорили, устанавливаются через параметры системы. Про настройку SAP системы через параметры я писал тут: часть 1, часть 2, часть 3. 

На рисунке 1 отображены основные области и соответствующие им параметры системы.

Рис. 1. Основные области памяти SAP и параметры.

Более детальное описание параметров по областям памяти представлено в таблице на рисунке 2.

Рис. 2. Параметры SAP для настройки памяти.

Установка значений этих параметров производится в профиле инстанции через транзакцию RZ10. Перед установкой параметра необходимо изучить справку по нему в транзакции RZ11 (рис. 3) и справку на SAP Help Portal. 

Рис. 3. Вызов справки по SAP параметру.

Будьте особо внимательны, учитывая единицы измерения каждого параметра и его влияние на ту или иную платформу. Большинство параметров используется для всех операционных систем, но есть и исключения (рис. 2). 

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

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

200. Юбилей

Вчера в моем блоге был размещен 200-й пост. Я считаю, что это, хоть и маленький, но юбилей. Ну и повод подвести итоги. :)

Первый пост в этом блоге был размещен 22 августа 2008 года. Он так и назывался "Первое сообщение. Полезные ссылки".

Таким образом, в августе 2015 года блогу исполнилось 7 лет. За эти 7 лет было написано 200 постов. С одной стороны это не так уж много, а с другой стороны, если посмотреть на статистику количества публикаций в блог по годам (рис. 1), то можно увидеть, что не всегда все было ровно и легко. :) Были периоды спада интереса или высокой загруженности по жизни, но я рад, что я не бросил это дело и продолжаю писать. Как я попал в SAP, вы уже читали. Как я начал писать в блог и зачем мне это, я надеюсь, как нибудь тоже напишу.

Рис. 1. Статистика количества постов по годам.

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

7 лет, 200 постов. Время идет, все меняется. Хотел бы провести несколько опросов.

В комментариях буду рад обратной связи: критике, пожеланиям, знакомству (в продолжении этого поста).


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

Маленькие эксперименты. Fake RAID

RAID массив это технология виртуализации данных, которая объединяет несколько дисков в логический элемент для избыточности и повышения производительности. В русской версии Википедии есть прекрасная статья про виды массивов. Поэтому повторяться здесь не буду. Остановлюсь лишь на том, что RAID массивы строятся с помощью RAID контроллеров, которые бывают трех видов:

• аппаратный RAID контроллер,
• программный RAID контроллер,
• аппаратно-программный RAID контроллер.

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

Третий вид - это чип, чаще всего, интегрированный в современные материнские платы для стационарных компьютеров, выполняющий часть работы на аппаратном уровне, а часть с помощью ресурсов основного процессора (необходима установка драйверов для ОС).

Как я уже упоминал в этом посте, у меня есть небольшой сервер для экспериментов и обучения. Сервер собран на базе 6-ти ядерного процессора AMD Phenom II X6 1055T, которому до сих пор нет адекватной по цене замены. :) В качестве материнской платы для моей системы была установлена модель ASUS M4A77T, которая имела на своем борту встроенный аппаратно-программный RAID контроллер. На тот момент у меня было 3 диска по 750 Гб, которые, ради эксперимента, я пробовал объединять в RAID массив. Ничего хорошего у меня тогда не вышло. Массив после 2-3-х недель работы сбоил, 'разваливался' и терял данные. И в таких видах RAID массивов (аппаратно-программный) я на тот момент разочаровался. После я даже узнал, что такие контроллеры называют fake RAID, что, согласитесь, не очень лестно. :)

В этом году я заменил материнскую плату на новую модель - ASUS M5A97 R2.0, оставив процессор и память из старой конфигурации. Новая материнская плата - новые эксперименты. :) На этот раз я работал с двумя дисками объемом 1 Тб каждый (модель WD Caviar Blue 7200 rpm 64 Mb).

Стоит отметить, что на данный момент, наибольшее распространение получили 3 уровня RAID:

• RAID 0 или striping - дисковый массив повышенной производительности, использующий для хранение данных чередование блоков данных (stripe), без отказоустойчивости, но чем больше дисков, тем больше производительность.
• RAID 1 или зеркало (mirroring) - массив из двух (или более) дисков, являющихся полными копиями друг друга. Обладает высокой отказоусточивостью, но низким коэффициентом использования дискового пространства.
• RAID 5 - дисковый массив с чередованием и «не выделенным диском чётности». Обладает самой низкой производительностью из данных трех, но оптимально использует дисковое пространство при хорошем уровне отказоустойчивости. Отлично подходит для хранения больших объемов данных - "дешево и сердито".

У меня стояла задача прежде всего получить ускорение при использовании обычных SATA3 дисков. Выбор пал в пользу RAID 0. Результаты тестов отображены на рисунках 1, 2 и 3.

Рис. 1. Тест чтения одиночного диска и RAID 0 массива.

Рис. 2. Тест записи одиночного диска и RAID 0 массива.

Рис. 3. Тест чтения/записи одиночного диска и RAID 0 массива.

На всех снимках экранов слева результаты теста одиночного диска, справа - RAID 0 массива на двух дисках. Операционная система на сервере - MS Windows 2008 Server.

Как видно из тестов, прирост производительности есть (гарантировано 60-70 %), и при чтении, и при записи. Стабильность работы контроллера - средняя. Ошибок, сбоев пока не было. 

Плюсы:

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

Минус один, но существенный:

• низкая отказоустойчивость.

Во-первых, вероятность выхода из строя диска в массиве увеличивается в 2 раза, чем в случае использования одного диска. Во-вторых, привязка данного вида RAID массива к контроллеру (как и в случае аппаратного RAID контроллера), в данном случае, ко всей материнской плате. То есть поиск не только отдельного контроллера, но и идентичной материнской платы, в случае выхода её из строя.

В целом, как мне кажется, решение на базе fake RAID имеет право на жизнь. Конечно, необходимо настроить систему резервного копирования для устранения минусов.

Еще хочу отметить, что система, установленная на данный RAID массив, работает гораздо веселее, даже по субъективным ощущениям. :)

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

Организация памяти в SAP AS ABAP - II

В первой части статьи про организацию памяти в SAP системе я обрисовал общую картину. Теперь вы знаете, что в SAP системе существует понятие виртуальной памяти, которая состоит из общей (Shared memory) и локальной (Local memory) памяти. Основные области памяти были также обозначены. Продолжим.

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

Во время входа в SAP систему каждый пользователь занимает небольшой объем памяти, который называется контекстом или начальным контекстом пользователя. В данном объеме памяти хранятся такие данные, как полномочия пользователя, значения SET/GET параметров и т.п. Во время работы пользователя в системе к его контексту добавляются данные необходимые для работы транзакций, например, номера документов. Логически и физически контекст каждого пользователя хранится в Roll area.

Стоит отметить, что когда пользователь открывает еще одну сессию (режим работы) в рамках одного логина в систему, нажимая в SAP GUI на панели кнопку "Create new session" (рис. 1), то создается еще одна копия контекста пользователя. Обе копии хранят данные отдельно друг от друга.

Рис. 1. Открытие новой сессии.

Все запросы от пользователей (шаги диалога) попадают в очередь к диспетчеру рабочих процессов, или ABAP диспетчеру. Он выбирает свободный рабочий процесс, который будет выполнять шаг диалога конкретного пользователя. Для выполнения шага диалога рабочему процессу необходимы данные текущего пользователя - его контекст. Процесс копирования контекста из Roll area в локальную память рабочего процесса называется roll-in (рис. 2).

Рис. 2. Мультиплексирование рабочих процессов.

После выполнения шага диалога, контекст выгружается из локальной памяти обратно в Roll area. Данный процесс, в свою очередь, называется roll-out. Ну и как я уже упоминал в первой части, Roll area состоит из двух областей - буфер в памяти и физический файл.

Последовательность выделения памяти для шага диалога в рамках рабочего процесса диалога (DIA WP) представлена на рис. 3.

Рис. 3. Выделение памяти для диалогового рабочего процесса.

1. Сначала для пользователя выделяется небольшой объем Roll area, который задается параметром ztta/roll_first. При рекомендуемом значении ztta/roll_first = 1, выделяется минимальный размер: в зависимости от релиза системы это около 100-200 Кб.
2. Если размер контекста пользователя растет, то используется память Extended memory. Тут стоит отметить, что данная память не копируется из Shared области в локальную область рабочего процесса, а выделяется блоками (параметр em/blocksize_KB = 1024 - менять по собственной инициативе не рекомендуется), а в контексте пользователя хранятся только указатели (pointers) на блоки в Extended memory (maping). Это обеспечивает быстрое переключение контекстов (roll-in/roll-out).
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, то программа прерывается с дампом, сообщающем о нехватке памяти.

Данная схема выделения памяти используется в диалоговых рабочих процессах на всех платформах и не-диалоговых рабочих процессах в операционной системе MS Windows.

Для не-диалоговых рабочих процессов в Unix картина несколько иная (рис. 4).

Рис. 4. Схема выделения памяти для не-диалоговых рабочих процессов в Unix.

Так как для не-диалоговых рабочих процессов (например, фоновых заданий или спула) не используется принцип мультиплексирования (то есть программа всегда полностью выполняется на одном рабочем процессе), то не стоит и задачи уменьшения локальной памяти рабочего процесса. Скорее наоборот, необходимо ограничить использование Extended memory не-диалоговыми процессами, оставляя весь объем для диалоговых пользователей. И это прекрасно достигается, использованием схемы, представленной на рис. 4.


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

Ошибка BR255W Cannot read from standard input

На одной из систем в журнале оффлайн бэкапа базы данных в DB13, который выполняется стандартными средствами SAP (утилита BRBACKUP), была постоянная ошибка-предупреждение (рис. 1). На создание резервной копии базы данных ошибка не влияла, но в глаза мне, как перфекционисту со стажем, всё время бросалась.

Рис. 1. Ошибка в DB13.

Несколько попыток решить проблему наскоком, результата не дали. Проблема совершенно не гуглилась и каждый раз я решал, что это какой-то глюк операционной системы MS Windows, на которой установлена система.

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

Рис. 2. Формат команды BRBACKUP.

Задания, которые мы планируем через "Календарь планирования операций базы данных" (транзакция DB13 или DBACOCKPIT), содержатся в таблице SDBAC. Открыв в транзакции SE16 содержимое таблицы SDBAC с фильтром DBSYS = 'ORACLE', обнаружил интересную картину (рис. 3).

Рис. 3. Записи таблицы SDBAC.

Опции для операции оффлайн бэкапа базы данных без журнальных файлов отличаются от опций всех остальных операций по созданию резервных копий базы данных. Отсутствующая опция '-c force' означает режим без участия пользователя, то есть без подтверждений и вопросов. Подробности об этой опции тут.

Как описано в SAP note # 859450 - Maintenance of the DB13-command table SDBAC, записи в этой таблице можно аккуратно корректировать, не меняя назначение операций в глобальном смысле. Таблица открыта на ведение. Добавляем опции в строку таблицы и сохраняем.

Рис. 4. Изменение записи в таблице SDBAC.

Результат: корректное создание оффлайн бэкапов базы данных без предупреждений и ошибок (рис. 5).

Рис. 5. Выполнение операции без ошибок и предупреждений.

Перфекционист во мне доволен. :)


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

Организация памяти в SAP AS ABAP - I

Данным постом я начинаю цикл статей посвященных производительности SAP систем.

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

• производительность и утилизация (оптимальное использование) аппаратной части,
• производительность операционной системы,
• производительность базы данных,
• производительность сервера приложений SAP (AS ABAP, AS JAVA) в целом и его частей.

Поговорим о памяти. Как вы знаете, на уровне операционной системы есть два понятия:

• физическая память (оперативная память, ОЗУ) - равна размеру физически установленной памяти в сервер.
• виртуальная память - равна сумме физической памяти и размеру swap области (paging area, файл подкачки). 

Виртуальная память ограничена двумя факторами - размер аппаратных ограничений (сумма физической памяти и swap области) и логические ограничения архитектуры. В 32-х битной архитектуре один процесс может адресовать теоретически максимум 4 Гб (2³²).  В реальности это даже меньше: в зависимости от типа операционной системы - от 2 до 3,8 Гб. Со стороны SAP установка 32-х битных версий на разные операционные системы описана в SAP note 146528 - Configuration of R/3 on hosts with much RAM. В случае 64-х битной архитектуры это число фактически не ограничено (16 Эб). Для использования 64-х битной архитектуры аппаратного обеспечения необходимо, чтобы операционная система, база данных и SAP kernel были 64-х битные. С 2007 года все продукты компании SAP устанавливаются только как 64-х битные с поддержкой Unicode.

На уровне сервера приложений SAP (AS ABAP) выделяют собственное понятие виртуальной памяти, которое включает в себя два вида памяти (рис. 1):

• shared memory - память доступная для всех процессов инстанции SAP AS ABAP,
• local memory - память доступная только для одного рабочего процесса системы.

Рис. 1. Типы памяти в SAP: общая картина.

Shared memory содержит следующие области:

• SAP буферы, которые содержат глобальные объекты для всех пользователей/процессов инстанции. 
• SAP roll memory, которая располагается в двух областях: памяти (Roll buffer) и на уровне файловой системы (SAP roll file). Cодержит начальный контекст пользователя (имя, полномочия, значения по умолчанию и т.д.), который генерируется единожды при входе в систему. 
• SAP paging memory так же состоит из двух частей - область в памяти (Paging buffer) и файл на уровне сервера приложений (SAP paging file). Содержит ABAP объекты (Data clusters и параметры для вызывающих программ и транзакций) во время выполнения операндов вида IMPORT/EXPORT FROM/TO MEMORY, SUBMIT REPORT, CALL TRANSACTION, CALL DIALOG и т.п. 
• Extended memory содержит данные для отдельных пользователей и их запущенных транзакций (внутренние таблицы, списки и т.п.). Даже если пользователь не запустил ни одной транзакции, место в Extended memory он занимает, так как там хранится вторая часть контекста пользователя. 

Local memory содержит следующие области:

• Local memory - локальные области для каждого рабочего процесса, которые содержат, например, SAP cursor cache (хранит и разбирает SQL запросы) и I/O буфер для передачи данных от и до базы данных.
• Heap memory - выделяется по требованию, если рабочему процессу не хватает Extended memory. Освобождается по окончанию шага диалога.

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

С днём знаний!

Поздравляю всех с днем знаний!

Хочу сообщить тем, кто еще не в курсе, что лето закончилось. Да, совсем. Да, больше не завезут. Да, следующее только в следующем году.

Наступил сентябрь. Пора что-то менять, может быть начать что-нибудь новое. Или, хотя бы, освежить память и голову после лета. :)

В связи с этим праздником, как и в прошлом году, я делаю скидку на первый обучающий пакет SAPADM_01. Тому, кто напишет мне на почтовый ящик shibolov@gmail.com до часа Х (а это 23:59 2 сентября 2015 года) я отдам его за 5 000* рублей. 
А тому, кто купит все пакеты (а их на данный момент 5), я так же сделаю скидку, и отдам их все за 20 000** рублей.

Условия акции: 
* - в случае покупки только первого пакета, его надо оплатить в течении сентября, 
** - в случае покупки всех пакетов, обучение надо оплатить в течении 2-х месяцев: сентября-октября.

Подробности про обучение тут.

Скидка только сегодня-завтра. 3-го сентября цена, как на странице с курсами и скидки пройдут. Да, совсем. Да, больше не завезут. Да, следующие только в следующем году. :)

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