14 октября 2015 г.

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.


12 октября 2015 г.

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

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

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

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

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




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

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


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


8 октября 2015 г.

Рабочие процессы в 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 для диалоговых рабочих процессов.



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


5 октября 2015 г.

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

В постах про память в SAP AS ABAP я уже рассмотрел следующие моменты:

Продолжим.

Мониторинг памяти в SAP AS ABAP инстанции производится с помощью транзакции ST02. Данная транзакция есть во всех версиях SAP систем (начиная с SAP_BASIS 46С точно) и, что немаловажно, между версиями нет больших отличий в интерфейсе и функциональности. На основном экране транзакции отображается информация о памяти в SAP инстанции (рис. 1).

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

30 сентября 2015 г.

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

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

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

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

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

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

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

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

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

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


29 сентября 2015 г.

200. Юбилей

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

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

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

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

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

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




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


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


28 сентября 2015 г.

Маленькие эксперименты. 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 массив, работает гораздо веселее, даже по субъективным ощущениям. :)