22 октября 2021 г.

Мастер-класс "SAP ландшафт и основы транспортной системы"

Коллеги, друзья и просто сочувствующие, хочу поделиться новостью. Во вторник, 9 ноября 2021 года, я буду проводить мастер-класс на площадке портала "SAPLAND". Мастер-классом назвать, наверное, это событие было бы слишком громко. Скорее это будет лекция "сборная солянка" на тему "SAP ландшафт и транспортная система". 



Попытаюсь за 4 часа рассказать всё, что знаю про транспортную систему в ABAP инстанции SAP системы, собрав в одном материале все нюансы и хитрости. Глубоко вглубь настройки и конфигурации не полезем, но в ширину постараюсь охватить всё. Будем говорить про базовые вещи, которые существуют в SAP системах с версии SAP R/3 3.0 и по сей день. При подготовке я постарался сделать материал максимально интересным для широкого круга специалистов. Ведь с транспортной системой сталкиваются и консультанты по модулям SAP системы, и ABAP-программисты, и SAP BASIS-консультанты/администраторы.

Если интересно, то регистрируйтесь и приходите. 
Формат мероприятия - онлайн. 
Физическим лицам скидка 30%.

Расписание всех мастер-классов этой осенней сессии можно найти по ссылке.

Обучение лучшее лекарство от осенней хандры! :)



18 октября 2021 г.

Повышенная нагрузка на систему от процессов rslgsend и rslgcoll

В 2012 году я опубликовал пост, где подробно описал процедуру перехода на новое SAP ядро 7.20 для систем на базе SAP NetWeaver 7.00 - 7.11. На текущий момент SAP ядро 7.20 не поддерживается, а для систем на базе SAP NetWeaver 7.00 - 7.31 рекомендуется перейти на версию ядра 7.22 EX2. Скорее всего данная ветка SAP kernel последняя (для этих версий систем) и будет поддерживаться до конца 2025 года (рис. 1).

Рис. 1. Окончание поддержки SAP kernel 7.22_EX2.

Если кто-то не знает про EX2, поясню. Для финальных версий SAP ядер, выше которых системы переводить не планируется, выпускают дополнительные ядра. Сначала с приставкой EXT, а потом EX2. В эти версии добавляют только самые критичные изменения для поддержки нового оборудования, безопасности или важных функций.

Для перевода систем на SAP ядро 7.22 EX2 следует руководствоваться SAP note # 2115344 - Installation of Kernel 722 (EXT/EX2). Помимо описания вполне стандартной процедуры обновления SAP ядра, там указано несколько нюансов, которые следует учитывать при переводе систем на это ядро. 

Во-первых, системы на базе SAP NetWeaver 7.00/7.01 не поддерживают механизм динамических рабочих процессов, который уже реализован в версиях SAP kernel 7.20 и выше. Про данный механизм я подробно писал в этом посте. Для корректной совместной работы ядра с такой системой эту функцию надо отключить через выставление следующих параметров инстанции:

rdisp/wp_no_restricted = 0
rdisp/configurable_wp_no = 0
rdisp/dynamic_wp_check = FALSE
rdisp/wp_max_no =
<сумма всех сконфигурированных рабочих процессов инстанции>

Второй момент, на который стоит обратить внимание, это новый формат центрального системного журнала SAP системы. Если у вас версия системы, основанная на SAP NetWeaver 7.00/7.01 (рис. 2) и работают процессы, отвечающие за центральный системный журнал (rslgsend и rslgcoll), то могут возникнуть проблемы с производительностью. Я с таким  столкнулся и хочу об этом рассказать.

Рис. 2. Пример версии системы на базе SAP NetWeaver 7.01.

Для начала пару слов о том для чего нужны эти процессы. В SAP системе, установленной на операционную систему Unix (любую её реализацию), в транзакции SM21 можно включить центральный системный журнал, который будет отображать журналы всех инстанций системы. Доступен он через пункт меню "System log -> Choose -> Central System logs". При этом в системах, работающих на операционной системе MS Windows центральный журнал не поддерживается. 

Принцип работы заключается в следующем. SAP ядро в специальной общей области памяти каждой SAP инстанции сохраняет локальный системный журнал (записи об ошибках и событиях инстанции). Выделенный процесс-демон с именем rslgsend пересылает эти записи центральному журналу выделенной инстанции (обычно это центральная инстанция системы). А на этой инстанции в свою очередь другой выделенный процесс коллектор (rslgcoll) собирает все записи вместе. Передача данных осуществляется по протоколу TCP, а процесс коллектор добавляет записи логов в файл центрального журнала, расположение которого задаётся через параметр rslg/central/file.  Вот на этой странице документации можно найти описание этого механизма.

Подробности же настройки упоминаются в SAP note # 25526 - Central system log not available. Стоит отметить, что часто функция центрального журнала активируется автоматически при установке SAP системы. Для старта вышеупомянутых процессов-демонов в стартовые профайлы инстанций добавляются строки для запуска вида:

#---------------------------------------------------------------------
# start rslgcoll
#---------------------------------------------------------------------
_CO =co.sap<SID>_DVEBMGS00
Execute_05 =local ln -s -f $(DIR_EXECUTABLE)/rslgcoll $(_CO)
Start_Program_05 =local $(_CO) -F pf=$(DIR_PROFILE)/<SID>_DVEBMGS00

#---------------------------------------------------------------------
# start rslgsend
#---------------------------------------------------------------------
_SE =se.sap<SID>_DVEBMGS00
Execute_06 =local ln -s -f $(DIR_EXECUTABLE)/rslgsend $(_SE)
Start_Program_06 =local $(_SE) -F pf=$(DIR_PROFILE)/<SID>_DVEBMGS00

Учтите, что здесь "Execute_XX" и "Start_Program_XX" должны иметь свой уникальный порядковый номер в зависимости от остальных аналогичных записей в профайле. 

Всё было бы хорошо, но начиная с версии SAP ядра 7.20 функции центрального журнала перекочевали в Web Services (процесс sapstartsrv), а процессы демоны (rslgsend и rslgcoll) больше не используются. Но системы с SAP_BASIS 7.00 или 7.01 новую версию центрального журнала использовать не могут, а для работы старой версии журнала при переходе на SAP ядро 7.20 процессы демоны передачи и сбора записей должны продолжать свою работу. И в этом случае, при их работе могут возникать коллизии с производительностью.

Процессы демоны начинают потреблять излишнее количество ресурсов: как процессорных (рис. 3), так и генерируя повышенный ввода-вывод на дисковую подсистему. Причем, ввод-вывод идёт на файловую систему, где хранится файл центрального системного журнала. В Unix системах  это директория /sapmnt/<SID>/global/. Ощущение, что процессы вхолостую постоянно пересоздают файл центрального системного журнала.

Рис. 3. Процессы-демоны в топе по потреблению процессорных ресурсов.

Решением данной коллизии является:
  1. Установка через транзакцию RZ10 параметра инстанции rslg/new_layout = 9.
  2. Остановка SAP инстанций.
  3. Удаление файла центрального журнала с уровня файловой системы.
  4. Старт SAP инстанций.

После этого процессы-демоны сразу успокаиваются и больше не тратят ресурсы системы впустую (рис. 4-8).

Рис. 4. Количество процессорного времени, съеденного демонами за неделю
без установки параметра.

Рис. 5. Количество процессорного времени, съеденного демонами за 3 дня
после установки параметра.

Рис. 6. График потребления процессорных ресурсов сервера.

Рис. 7. График нагрузки на СХД по SAN.

Рис. 8. График операций записи в файловую систему /sapmnt сервера.

На графиках разница видна невооружённым взглядом.

Проблема описана в SAP note # 1517379 - Which system log format does the 720 kernel write? Будьте внимательны и выполняйте все рекомендации компании SAP. 


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


4 октября 2021 г.

Сколько рабочих процессов в AS ABAP инстанции может быть?

Как я уже много раз упоминал в своих постах, рабочими лошадками в AS ABAP инстанции SAP системы являются рабочие процессы (work processes или WP). Управляет ими ABAP диспетчер, который запускает и останавливает рабочие процессы, а так же выдаёт каждому задачу из очереди запросов (рис. 1).

Рис. 1. Архитектура ABAP части системы SAP NetWeaver 7.1.

В ABAP инстанции трудятся рабочие процессы нескольких типов. 

Запросы от диалоговых пользователей обрабатывают диалоговые рабочие процессы (тип DIA), которых в системе обычно большинство. 

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

При отправке документа из SAP системы на печать включаются в работу специальные рабочие процессы спула (SPO). Подробности про настройку принтера в AS ABAP инстанции можно найти в серии постов

Если пользователь или фоновое задание изменяет данные в таблицах базы данных, то эти запросы обрабатывают процессы обновления. Причём их можно настроить два типа: UPD и UP2.

Дополнительно для поддержания целостности данных перед обновлением выполняется блокировка объектов на уровне сервера приложений. За это отвечает отдельный тип рабочих процессов - блокировки (ENQ). Правда, в последних версиях SAP систем этот процесс перекочевал в отдельный Enqueue Server, который вместе с Message Server входит в состав отдельной инстанции - ASCS. Про это я рассказывал в этом посте. Такое изменение в архитектуре SAP системы позволяет строить более надёжные и отказоустойчивые программные комплексы. 

Текущий состав рабочих процессов AS ABAP инстанции можно посмотреть в транзакциях мониторинга рабочих процессов - SM50 и SM66 (подробнее про эти транзакции). 

Изменение же количества рабочих процессов того или иного типа осуществляется через параметры SAP системы. Параметры, так или иначе влияющие на количество рабочих процессов, я объединил в таблицу (рис. 2).

Рис. 2. SAP параметры для настройки рабочих процессов ABAP инстанции.

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

Для динамического же изменения количества рабочих процессов инстанции в SAP системе можно настроить режимы работы (operation modes). Благодаря этому механизму можно, не меняя общего количества рабочих процессов, менять их типы. Например, на ночь переводя часть рабочих процессов диалогового типа в фоновые, а утром возвращая обратно. 

Для настройки режимов работы используются транзакции RZ03/RZ04. Напоминаю, что в моём обучающем курсе SAPADM 2.0 (Пакет 2. Задание 1) можно поупражняться в их настройке в собственной учебной среде. 

Помимо настройки режимов работы в системах, основанных на SAP NetWeaver 7.02 или выше, существуют еще 2 механизма динамического увеличения количества рабочих процессов:

  • зарезервированные (stand-by) рабочие процессы,
  • динамические рабочие процессы.

Зарезервированные (stand-by) рабочие процессы бывают только диалоговые (тип DIA). Они, как и другие рабочие процессы, запускаются при старте инстанции, но находятся в режиме Standby. В случае если ABAP диспетчер не может выделить запросу пользователя свободный диалоговый рабочий процесс, то есть в системе наблюдается критическая нехватка свободных диалоговых рабочих процессов, то система автоматически переводит зарезервированные рабочие процессы в рабочий режим. Количество рабочих процессов такого типа настраивается через значение параметра rdisp/wp_no_restricted. По умолчанию параметр равен нулю, то есть механизм зарезервированных рабочих процессов деактивирован.

Для временного решения проблем с нехваткой рабочих процессов диалога или спула система автоматически запускает динамические рабочие процессы. Их количество равно количеству, заданному в параметре rdisp/wp_max_no, минус общее количество статических рабочих процессов (включая зарезервированные рабочие процессы, если они настроены).

Динамические рабочие процессы в системе есть всегда и их количество, по умолчанию равно 5, так как параметр rdisp/wp_max_no рассчитывается по формуле: сумма всех статических рабочих процессов плюс пять. Менять значение параметра вручную стоит только в том случае, если вы планируется установить количество таких процессов больше 5 (рис. 3).

Рис. 3. Формула для расчёта значения параметра rdisp/wp_max_no.

Динамические рабочие процессы запускаются и останавливаются автоматически. Время жизни таких процессов после нормализации ситуации в системе можно задать через значение параметра rdisp/max_dynamic_wp_alive_time. По умолчанию, срок их жизни 5 минут (300 секунд).

Параметр rdisp/configurable_wp_no используется для настройки режимов работы (operation modes). Он показывает количество статических рабочих процессов системы. Благодаря ему при любом режиме работы в системе могут активироваться динамические рабочие процессы. Вручную изменять его значение, рассчитываемое по формуле (рис. 4), не рекомендуется (только в крайних случаях по рекомендации SAP).

Рис. 4. Формула для расчёта значения параметра rdisp/configurable_wp_no.

Количество зарезервированных и динамических рабочих процессов (если они вдруг запущены), также отображается в транзакции SM50.

Теперь вернёмся к вопросу заданному в заголовке: каковы крайние значения количества рабочих процессов в AS ABAP инстанции? 

Как видно из таблицы, минимальное количество в сферической ABAP инстанции в вакууме это 2 диалоговых рабочих процесса. Правда в реальности вы такое вряд ли увидите. Если только на выделенной дополнительной диалоговой инстанции. И даже в этом случае на ней диалоговых процессов будет больше двух. А после установки любой SAP системы, на единственной её инстанции всегда будут рабочие процессы всех типов. Ну кроме рабочего процесса блокировки по вышеупомянутой причине. Для всей SAP системы существуют следующие рекомендации и ограничения:

  • количество диалоговых процессов должно быть не меньше, чем общее количество рабочих процессов других типов на текущей инстанции,
  • UP2 процессов может не быть, тогда все обновления будут осуществляться процессами типа UPD,
  • рабочих процессов типа BTC должно быть как минимум 1 на всю систему,
  • процесс блокировки ENQ чаще всего один; если их несколько (очень большая система), то они все должны быть на одной инстанции,
  • SPO процесс должен быть тоже как минимум 1 на всю систему.

Максимальное же общее количество рабочих процессов инстанции (с учетом динамических и зарезервированных) может достигать 512 (для современных систем, включая ABAP Platform). Данный лимит актуален для систем, начиная с SAP BASIS 7.1 (с определённым пакетом поддержки), а до этого он был гораздо скромнее. Например, в SAP NetWeaver 7.0 рабочих процессов основных типов (кроме ENQ) может быть не больше 100 (рис. 5).

Рис. 5. Граничные значения диалоговых рабочих процессов в SAP NetWeaver 7.0.

Для систем на SAP NetWeaver 7.0 и ниже я встречал рекомендации, что при приближении общего количества рабочих процессов AS ABAP инстанции к 100, необходимо разворачивать дополнительную инстанцию. И, с учётом ограничений по параметрам, даже на очень крупных проектах вы вряд ли встретите больше 200 рабочих процессов на одну ABAP инстанцию.

А как определить, что количество рабочих процессов того или иного типа в вашей инстанции избыточно? Ведь каждый лишний рабочий процесс AS ABAP инстанции это процесс на уровне операционной системы. А каждый процесс на уровне операционной системы требует ресурсов (особенно памяти). Поэтому излишнее количество рабочих процессов может снижать производительность всей системы и увеличивать время обслуживания (запуск/останов/рестарт и так далее). Здесь может помочь просмотр актуального времени работы отдельных рабочих процессов в транзакции SM50 (я рассказывал об этом в этом посте). Но имейте ввиду, что этот способ работает только для систем, основанных на SAP NetWeaver версий ниже, чем 7.20. В более старших релизах SAP диспетчер распределяет нагрузку по существующим рабочим процессам более равномерно, вне зависимости от их количества. И так легко лишние процессы уже не вычислить.

Дополнительную информацию по этой теме можно найти в SAP notes:


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