Повышенная нагрузка на систему от процессов 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. 

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

Особенности конфигурации файла /etc/services для SAP в SUSE Linux

Как знают постоянные читатели моего блога, в последнее время я начал плотно работать с операционной системой Linux (в частности SUSE Linux) в качестве платформы для разворачивания SAP систем. Сегодня расскажу ещё об одной особенности, с которой лично столкнулся.

После базовой установки ABAP-части SAP системы на операционную систему SUSE Linux обнаружил, что не корректно работают некоторые транзакции. В частности, транзакции, которые используются в системе с несколькими серверами приложений (я упоминал про это в этом посте). Прежде всего это транзакция AL08 - просмотр пользователей всех серверов приложений, выполнивших вход в систему. Также проблемы возникают в транзакциях SM21 (системный журнал) и SM20 (журнал безопасности) при попытке дистанционно просмотреть журналы других инстанций. Например, на начальном экране транзакции AL08 в старых версиях SAP систем не отображается ни одной активной инстанции, даже текущей (рис. 1).

Рис. 1. Не корректно работающая транзакция AL08.

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

Дело в том, что внутри данных транзакций используется функциональный модуль TH_SERVER_LIST (для просмотра используем транзакцию SE37), который в свою очередь вызывает внутреннюю C-функцию SAP ядра ThSysInfo (рис. 2).

Рис. 2. Пример исходного кода функционального модуля TH_SERVER_LIST.

Если мы попробуем протестировать работу данного функционального модуля, нажав на панели соответствующую кнопку (рис. 3).

Рис. 3. Тестирование работы функционального модуля TH_SERVER_LIST.

На следующем экране, не указывая параметров, выполним модуль (рис. 4).

Рис. 4. Тестирование работы функционального модуля TH_SERVER_LIST.

Для просмотра результатов необходимо щелкнуть на строке таблицы LIST напротив надписи "Результат" (рис. 5).

Рис. 5. Просмотр результатов теста.

На экране появится строка таблицы (рис. 6).

Рис. 6. Просмотр результатов теста.

Функциональный модуль вызывает функцию SAP ядра, которая должна вернуть имя сервиса или номер порта текущей инстанции SAP системы. А в данном случае мы видим какой-то tick-port. Что это? 

Дело в том, что во всех Unix-like операционных системах сервисы, которые работают в системе, должны быть зарегистрированы. Имена сервисов, используемые ими порты и протоколы описаны в файле /etc/services.

К слову сказать, в MS Windows этот файл тоже есть и находится по пути - C:\Windows\System32\drivers\etc\services.

Если сервис не зарегистрирован, то есть не описан в этом файле, то ни одно приложение не может его использовать. Инстанции SAP системы не исключение и все свои сервисы должны описать в этом файле. Строки обычно добавляются автоматически в конец файла в процессе инсталляции SAP системы (рис. 7).

Рис. 7. Пример строк SAP системы в файле /etc/services.

Но разработчики операционных систем семейства Linux, в частности SUSE Linux, решили добавить в этот файл все возможные сервисы, которые могут быть в системе. Наверное, это сделали из лучших побуждений - чтобы потом после разворачивания почти любого приложения, всё работало. В итоге, сразу после инсталляции операционной системы данный файл уже имеет больше 12 000 строк сервисов!

Детальный анализ показал, что с номером порта, который используется текущей инстанцией, в этом файле уже есть записи (рис. 8).

Рис. 8. Строки с нашим номером порта для сервиса Tick Port.

Узнаёте? :) Это и есть то, что возвращает наша функция SAP ядра. То есть происходит поиск по номеру порта до первого совпадения. Имя сервиса считывается и передаётся ABAP-программе.

Решением данной проблемы может быть удаление или комментирование всех строк, в которых используются порты SAP системы. Этот список я приводил в этом посте. Так как портов очень много, то эта задача может быть не простой. По-хорошему стоит ещё и проанализировать какие сервисы используются в системе, а какие нет. Чтобы случайно что-нибудь не сломать.

Поэтому я применил другое решение. Можно после установки SAP системы перенести строки с сервисами SAP системы из конца файла /etc/services в его начало (рис. 9).

Рис. 9. Перенос строк с SAP сервисами в начало файла /etc/services.

Тогда функциональный модуль TH_SERVER_LIST будет находить верное вхождение сервиса в файле, так как оно стоит первым, и выдавать корректный результат (рис. 10).

Рис. 10. Пример корректной работы функционального модуля.

И если в работе транзакций были проблемы по вышеописанной причине, то они исчезнут. Только имейте в виду, что для применения изменений возможно придётся выполнить рестарт SAP системы.

Надеюсь, что эта информация кому-то пригодится.

Похожие проблемы описаны в SAP notes:

• 947726 - Sec audit: SM20 does not display all existing servers,
• 2135427 - TH_SERVER_LIST Does Not Provide Dispatcher Service.

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

Центральный системный журнал SAP

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

Но есть способ упростить себе жизнь. :) В транзакции SM21 можно выбрать другой вид системного журнала.

По-умолчанию, используется "Локальный журнал". При выборе пункта меню "Дистанционный журнал" или "Центральный системный журнал" на экране выбора появляется поле "Имя инстанции", в котором можно указать инстанцию любого сервера приложений системы.

Таким образом можно посмотреть системный журнал любого сервера приложений, не входя на каждый из них локально. Но это не самое интересное.
Если выбрать пункт меню "Все дистанционные системные журналы" или поставить * в поле "Имя инстанции", то отчет выдаст то, что нам всем и нужно, сводный системный журнал с указанием в дополнительном поле имени инстанции, "автора" сообщения.

В курсе ADM100 (SAP Web AS Administration I) указано, что центральный системный журнал возможен только на Unix-серверах. Еще один плюс в пользу этой операционной системы.

P.S. И не забудьте позаботиться о подарках родным, любимым и друзьям. ;)

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

Журналы SAP-системы

Основной системный журнал SAP системы можно увидеть запустив транзакцию SM21 (Tools -> Administration -> Monitoring -> System Log). Отображаются сообщения с текущей SAP-инстанции. Записи журнала считываются из файла, который задан параметром rslg/local/file. По умолчанию, /usr/sap/<sid>/<Instance_name>/log/SLOG<instance_number>. Параметр rslg/max_diskspace/local задает размер файла системного журнала. По умолчанию, 500000. После заполнения - старые записи удаляются. Размер одной записи 192 байта. Можно собирать записи журналов со всех серверов приложений на центральной инстанции. Для этого необходимо выставить ряд параметров. Подробности на SAP Help Portal.

Транзакция ST22 - просмотр ABAP-дампов системы. Можно через меню "Перейти к -> Реорганизовать" установить срок хранения дампов. Величина срока хранения дампов зависит от частоты анализа Ваших систем. Обычно, 7 дней вполне достаточно. Дампы хранятся в таблице SNAP.

Можно включить Security Audit Log системы. Из данного журнала можно увидеть удачные и неудачные входы пользователей в систему, блокировку пользователей, запуск транзакций, отчетов, изменения основных записей пользователей. Временно включается в транзакции SM19. Постоянно параметром rsau/enable=1. Параметр rsau/local/file задает директорию где будут хранится журналы. По умолчанию, /usr/sap/<sid>/<Instance_name>/log/audit_<instance_number>. Через параметр rsau/max_diskspace/local задается размер аудит-файла за день. Просмотр журнала через транзакцию SM20. Удаление старых журналов - транзакция SM18.

Также есть возможность активировать аудит изменений в таблицах. В профиле прописать параметр rec/client = XXX (номер манданта). Можно задать несколько мандантов через запятую. Для нужных таблиц в SE11 в технических параметрах настройки включить "журнал изменений". Просмотр аудита - транзакция SCU3. Журнал аудита хранится в таблице DBTABLOG.

Я описал здесь не все журналы. Помните, что любое журналирование, особенно дополнительное, в той или иной степени уменьшает производительность системы.

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