Когда возникает системный дамп MEMORY_NO_MORE_PAGING

Сегодняшним постом я снова обращусь к теме организации памяти на сервере приложений SAP AS ABAP. Поговорим про системный дамп MEMORY_NO_MORE_PAGING. Обычно такой дамп возникает не один, а генерируется массово. Причём одновременно у нескольких пользователей одной SAP инстанции (рис. 1 и 2).  

Рис. 1. Пример генерации системных дампов типа MEMORY_NO_MORE_PAGING.

Рис. 2. Пример системного дампа MEMORY_NO_MORE_PAGING.

Данный сбой происходит тогда, когда рабочий процесс инстанции SAP системы, выполняющий ABAP-код, не может получить очередную порцию памяти из Paging Area (или SAP paging memory). В данной области хранятся временные ABAP объекты (Data clusters и параметры для вызывающих программ и транзакций), создаваемые во время выполнения операндов вида IMPORT/EXPORT FROM/TO MEMORY, SUBMIT REPORT, CALL TRANSACTION, CALL DIALOG и так далее (рис. 3). Про эту область я уже упоминал в нескольких своих постах (ссылка 1, ссылка 2).

Рис. 3. Примеры операндов, использующих Paging Area.

Анализ текущего размера и использования Paging Area осуществляется в транзакции ST02 (рис. 4).  

Рис. 4. Мониторинг использования Paging Area.

Возможен так же просмотр не только текущего и максимально использованного размера области, но и исторических данных. Для этого необходимо дважды щелкнуть мышью на имя области "Paging area". По информации на открывшемся экране можно проанализировать, например, в какой день использование данной области достигло своего максимума (рис. 5).

Рис. 5. История использования Roll и Page областей инстанции.

Как вы можете заметить, данные в историю попадают каждый день в 22:28. А это явно не пиковое рабочее время системы. Поэтому большого смысла анализировать значения в поле "Used" на этом экране нет.

Paging Area состоит из двух частей: область в памяти - SAP paging buffer и файл на уровне сервера приложений - SAP paging file. В данном случае (рис. 4) можно заметить, что область заполнена почти на 94%. И если рабочие процессы текущей инстанции будут запрашивать место в Paging Area и дальше (но при этом не освобождать его), то область переполнится. И, как результат, в системе начнут генерироваться системные дампы типа MEMORY_NO_MORE_PAGING (рис. 1 и 2). 

Настройка размера области производится с помощью двух параметров инстанции: rdisp/PG_SHM и rdisp/PG_MAXFS. Единица измерения - блоки по 8 Кб. Первый параметр задаёт размер области Paging Area в оперативной памяти, а второй - общий размер, равный сумме Paging buffer и Paging file. При этом местоположение файла задаётся через параметр DIR_REORG. По умолчанию это /usr/sap/<SID>/<Instance>/data, а имя файла - PAGFIL<Instance_number>.

Чем больше будет часть Paging Area находящаяся в оперативной памяти, тем выше будет производительность операций при работе с ней. В идеале, можно выставить rdisp/PG_SHM = rdisp/PG_MAXFS. Как вы понимаете, в этом случае вся область будет располагаться в оперативной памяти. 

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

Но здесь кроется одна проблема. На системах, основанных на SAP NetWeaver версии 7.0 и ниже, максимальное значение параметра rdisp/PG_MAXFS указано равным 262 144 (рис. 6). Это соответствует размеру области равному 262 144 * 8 Кб = 2 Гб.  

Рис. 6. Описание параметра rdisp/PG_MAXFS в системе SAP NetWeaver 7.0.

Я столкнулся с тем, что на инстанции SAP системы периодически не хватает Paging Area, состоящей из 1,5 Гб в оперативной памяти плюс 500 Мб на диске. И получается, что дальше увеличивать область нельзя.

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

• # 133909 - Maximum value for PG_MAXFS, PG_SHM, ROLL_MAXFS, ROLL_SHM,
• # 1081722 - SAP Paging in shared memory.

В этих документах сказано, что ограничение на параметр наложено из-за поддержки 32-битных систем. Такая разрядность систем ограничивает область памяти процесса 2 Гб. Но на практике, даже на такой системе, можно устанавливать размер области = 2 Гб + область памяти. То есть ограничение можно записать в виде rdisp/PG_MAXFS = 250 000 + rdisp/PG_SHM. Параметр rdisp/PG_SHM, в свою очередь, тоже может быть 2 Гб. 

А для 64-битных систем нет даже таких ограничений. Главное, чтобы файловая система поддерживала файлы размером больше 2 Гб. Ну, а предупреждение в транзакции RZ10, можно проигнорировать. 

Аналогичные утверждения верны и для области Roll Area.

В SAP NetWeaver 7.50 такого ограничения уже нет. Может быть в системах между этими релизами то же где-то увеличили максимальное значение. Не удивлюсь, если это было сделано в SAP NetWeaver 7.40. Но, согласно описанию параметра в SAP NetWeaver 7.50, Paging Area уже может достигать 12 500 000 * 8 Кб = 95 Гб (рис. 7).

Рис. 7. Описание параметра rdisp/PG_MAXFS в системе SAP NetWeaver 7.5.

А я на своей старой системе, не смотря на максимальное ограничение в 2 Гб, настроил новый размер Paging Area равный 2 Гб в оперативной памяти и 1 Гб на файловой системе:

rdisp/PG_SHM = 250 000

rdisp/PG_MAXFS = 375 000

Изменения системой после рестарта подхватились успешно (рис. 8). Буду наблюдать за работой системы дальше.

Рис. 8. Размер Paging Area после изменения параметров.

Настроив Paging Area таким образом, теперь уже можно пойти к программистам и научить их программировать попросить их проанализировать код программ на предмет оптимизации использования данного вида памяти. И задача из критической превращается в плановую.

Одновременно из этой истории можно сделать такой вывод: иногда, при установке параметров SAP инстанции предупреждения в RZ10 можно проигнорировать. Главное, чтобы вы были уверены в том, что делаете и понимали базовые процессы в системе. 

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

Тюнинг настроек памяти AS ABAP инстанции на реальном примере: результаты

В прошлом посте я описал проблему, с которой ко мне обратился коллега. По словам коллеги, SAP система работала медленно, а многие рабочие процессы AS ABAP инстанции переходили в PRIV режим работы. Анализ показал, что размеры буферов и общих областей памяти SAP инстанции нуждаются в корректировке. Мною были составлены рекомендации, которые были успешно применены к системе. И в этом посте мы проанализируем результаты тюнинга. 

Итак, с помощью SAP параметров были увеличены некоторые области памяти и буферы инстанции. В результате этого общая виртуальная память SAP инстанции выросла на 5,5 Гб (рис. 1 и 2).

Рис. 1. Виртуальная память SAP инстанции до корректировки. 

Рис. 2. Виртуальная память SAP инстанции после корректировки.

Но, как вы помните из прошлого поста, объём оперативной памяти сервера составляет 256 Гб, что вполне достаточно для увеличенного объёма памяти SAP инстанции. Поэтому и после увеличения аппетитов SAP инстанции swap область на сервере не используется (рис. 3). А значит  эффективность работы с памятью на уровне операционной системы не упала.

Рис. 3. Вывод команды top на сервере после корректировки.

Корректировки параметров были сделаны 14 апреля. После этого система проработала чуть больше недели. Основной экран транзакции ST02 на данный момент выглядит следующим образом (рис. 4). Инстанция перезагружалась 15 апреля, снимок экрана сделан 23 апреля (1).

Рис. 4. Основной экран транзакции ST02 после корректировки.

Какие выводы, глядя на этот экран, можно сделать:

1. Из Program Buffer (2) используется почти 800 Мб и на данный момент размера в 1 200 Мб достаточно. Ясно, что предыдущего размера в 300 Мб катастрофически не хватало. Параметры, отвечающие за этот буфер, пока корректировать нет необходимости.
2. Объёма CUA Buffer (2) системе до сих пор не хватает. Хотя количество swaps снизилось, но буфер надо бы увеличить ещё. Причём, обратите внимание, что не хватает именно объёма, а не максимального количества записей. Кто-то внимательный заметит, что я рекомендовал в прошлый раз размер буфера равный 6 000 Кб, а по факту он стоит 9 000 Кб. Дело в том, что по нему один раз уже были повторные корректировки: 15 апреля поднимали его размер ещё на 3 000 Кб. Поэтому изначальные изменения параметров были сделаны 14 апреля, а инстанция была повторно перезагружена 15 апреля, именно из-за CUA Buffer.
3. Размер Screen Buffer (2) требованиям системы удовлетворяет гораздо лучше, чем CUA. Можно было бы его не трогать. Но памяти на сервере много и размер буфера не большой, поэтому рекомендуется также немного увеличить и его. 
4. Пиковое использование области памяти Extended Memory (3) было зафиксировано на уровне 6 Гб. Из этого ясно, что предыдущего объёма в 4 Гб было недостаточно. Система с новыми значениями параметров проработала ещё мало. Но, так как рабочие процессы инстанции используют эту память в большом объёме и, памяти на сервере достаточно, я бы сразу порекомендовал ещё немного её увеличить. А после этого понаблюдать за системой на большем промежутке времени. 
5. Пиковое использование области Paging Area (3) за это время достигало более 400 Мб при размере области 256 + 256 = 512 Мб. В прошлый общий объём в 256 Мб, опять же, явно система упиралась. На втором шаге корректировки я бы рекомендовал увеличить ту часть этой области, что находится в оперативной памяти, соответственно увеличив общий объём.

Остальные области я бы пока не трогал. И даже буфер Tables: Generic Key, не смотря на наличие 2-х swaps за 8 дней работы. Как показывает практика, небольшое количество swaps при работе этого буфера будет почти всегда.

Напомню ещё раз: угадать с первого раза со 100% точностью оптимальный размер буферов и областей не получится. Обычно процесс настройки состоит из нескольких шагов. Мои рекомендации на данном шаге это необходимость изменить значения следующих параметров:

• rsdb/cua/buffersize = 12 000
• zcsa/presentation_buffer_area = 12 000 000
• em/initial_size_MB = 10 240
• rdisp/PG_SHM = 65 536
• rdisp/PG_MAXFS = 98 304

Ну и на последок, давайте посмотрим, а как изменилась производительность системы не по субъективным ощущениям, а по объективным данным - цифрам. 

Базовым показателем производительности системы является среднее время отклика системы. При диалоговом режиме работы пользователей этот параметр - это среднее время отклика системы на шаг диалога. Общее время, которое система обрабатывала диалоговые шаги в рабочих процессах типа DIA, делится на количество выполненных шагов. Получается среднее время выполнения одного шага диалога. 

Корректно настроенная SAP система собирает эту информацию на постоянной основе с помощью служебных фоновых заданий. И результаты собранной статистики можно посмотреть в транзакции ST03 (ST03N). 

Как я уже написал выше, параметры были скорректированы 14 апреля. Посмотрим среднее время отклика системы за следующие недельные периоды:

• 29.03.2021 - 04.04.2021 (рис. 5),
• 05.04.2021 - 11.04.2021 (рис. 6),
• 12.04.2021 - 18.04.2021 (рис. 7),
• 19.04.2021 - 25.04.2021 (эта неделя) (рис. 8).

Рис. 5. Показатели времени отклика системы за период до корректировки -1.

Рис. 6. Показатели времени отклика системы за период до корректировки - 2.

Рис. 7. Показатели времени отклика системы за период после корректировки - 1.

Рис. 8. Показатели времени отклика системы за период после корректировки - 2.

Такого результата не ожидал даже я. Среднее время реакции системы на шаг диалога сократилось с 3,4 - 4,4 секунды до 0,8 - 0,7 секунды. То есть, как минимум в 4 раза! Сокращение времени отклика произошло за счёт интервалов, когда выполнялась работа на центральном процессоре. То есть раньше вместо расчётов, система занималась борьбой за ресурсы памяти. 

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

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

Тюнинг настроек памяти AS ABAP инстанции на реальном примере

В моём блоге можно найти несколько хороших статей про организацию памяти в AS ABAP инстанции. Во первых, это цикл статей, ссылки на которые доступны в посте "Организация памяти в SAP AS ABAP. Заключение", а во вторых, статьи про буферы инстанции - "SAP буферизация. Заключение". Если вы не читали их, то настоятельно рекомендую ознакомиться.

Не достаточно просто купить сервер с большим объёмом оперативной памяти. Ни сервер приложений SAP, ни база данных не смогут использовать оперативную память больше того предела, который настроен через соответствующие системные параметры. 

Про важность настройки размеров буферов для базы данных Oracle я уже писал в этом посте. 

А что касается сервера приложений SAP, то каждый прекрасно понимает, что буферы и общие области оперативной памяти, используемые инстанцией SAP, имеют непосредственное влияние на производительность всей системы в целом. Причём, недостаточно один раз настроить размеры данных областей и успокоиться. Любая SAP система постоянно развивается: увеличивается количество пользователей, активируется новая функциональность системы, появляются новые процессы и программы, увеличивается объем хранящихся и обрабатываемых данных. Ну и, не в последнюю очередь, периодически обновляется сама система. Поэтому необходимо постоянно следить за тем, как система использует области памяти, отслеживать метрики производительности, анализировать показатели. И если это необходимо, то вносить изменения в конфигурацию через параметры SAP системы. При этом хороший администратор должен делать это до наступления критической ситуации, работая проактивно, а не реактивно. Я надеюсь, что этот пост поможет вам отточить "своё кунг-фу" по тюнингу параметров памяти SAP инстанции. :)

Ко мне обратился коллега, который попросил помочь настроить параметры использования памяти на одной из SAP систем. Причиной обращения были факты медленной работы системы и большого количества процессов в PRIV режиме (транзакция SM50) (рис. 1). 

Рис. 1. Список рабочих процессов в PRIV режиме.

Для начала необходимо собрать информацию о системе. Версия SAP системы - SAP ERP 6.0 с SAP_BASIS 700 и ядром 7.22 (рис. 2-4).

Рис. 2. Информация по версии системы - 1.

Рис. 3. Информация по версии системы - 2.

Рис. 4. Информация по версии системы - 3.

Платформа, как видно из этих же скриншотов, Solaris (SunOS 5.11), а в качестве базы данных используется Oracle 11.2. 

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

Оперативной памяти на сервере достаточное количество - 256 Гб (рис. 5). Памяти на уровне операционной системы хватает - область подкачки не используется (рис. 6). При этом мне известно, что весь сервер отдан текущей SAP системе, включающей в себя сервер базы данных и центральную инстанцию SAP.

Рис. 5. Информация из транзакции ST06.

Рис. 6. Вывод команды top на уровне операционной системы сервера. 

Я не знаком с особенностями и нюансами работы с оперативной памятью в операционной системе Solaris, но буду исходить из общих знаний работы Unix с памятью. Читали мой пост про оперативную память в Linux? Всё, что не отдано приложениям, операционная система использует под свои буферы, в частности, под файловый кэш. Но тут мы видим, что даже с учётом этого свободно 12 Гб оперативной памяти. И самый главный критерий, повторюсь, полностью свободная swap область.

Основным буферам базы данных Oracle отдано порядка - 35 Гб и 36 Гб (рис. 7). Суммарно получается около 71 Гб, что так же можно наблюдать у процессов "oracle" на уровне операционной системы (рис. 6). Целесообразность размеров буферов базы данных я здесь рассматривать не буду. У SAP есть рекомендации по параметрам базы данных Oracle, которые отражены в соответствующих SAP notes (вот эта статья, рис. 1). Отмечу лишь тот факт, что хорошая эффективность буфера в текущей системе подтверждена соотношением физических и логических чтений из базы данных (рис. 7). 

Для решения текущей задачи фиксируем, что серверу базы данных отдано порядка 71 Гб общей оперативной памяти. Значит, серверу приложений SAP можно отдать не меньше.

Рис. 7. Информация по производительности Oracle из транзакции ST06.

Вернувшись к основной проблеме, напомню, что переход рабочего процесса в PRIV режим происходит тогда, когда ему не хватает памяти из области Extended Memory и он начинает использовать SAP Heap Memory. Кто не помнит, читаем вот этот пост. Это может происходить, если квота, ограничивающая процессу память из Extended Memory, мала, или же, когда размер этой области слишком мал для текущего количества работающих в системе пользователей.

Основной инструмент для мониторинга использования памяти и буферов SAP инстанции это транзакция ST02. Заглянем в неё на текущей системе (рис. 8). 

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

Глядя на экран, первое, что бросается в глаза сразу, это большое количество вытеснений из буфера (swaps) для следующих буферов инстанции:

• Program buffer (3),
• CUA buffer (3),
• Screen buffer (3),
• Tables buffers - оба (4),
• Export/Import buffer (5).

Рис. 8. Снимок экрана транзакции ST02.

Читая документацию, можно сделать вывод, что определённое количество вытеснений из буферов допускается, но в идеале должно стремиться к нулю. К тому же, если вы заметите, данные буферы имеют очень небольшой размер, а влияние на производительность оказывают существенное. А текущий сервер, как мы уже выяснили, имеет на своём борту достаточное количество свободной оперативной памяти. Как мне кажется, наблюдаемые значения похожи на те, что устанавливаются в этой версии системы по умолчанию после установки, но они малы даже для систем разработки и настройки. 

Так что моя первая рекомендация в данном случае: увеличить вышеперечисленные буферы SAP инстанции. 

Обычно буфер определяется двумя параметрами: максимальный размер в байтах и максимальное количество хранимых записей (поля "Dir. Size"). Но при этом у Program Buffer и CUA Buffer один параметр - размер, а количество записей рассчитывается системой исходя из размера самого буфера. 

Текущие значения ключевых, в данном случае, параметров и рекомендации по их изменению представлены в таблице (рис. 9).

Рис. 9. Рекомендации по настройке буферов SAP инстанции.

Теперь переходим к общей памяти (рис. 8, поле 6). По многим областям зафиксировано достижение максимального размера областей (поле "MaxUse [KB]"). Это означает, что хотя бы однажды за период мониторинга данные заполняли буфер полностью и системе его не хватало. Чаще всего такая ситуация проявляется через генерацию ABAP-дампов того или иного типа. Поэтому тут так же рекомендация - увеличить размеры областей памяти Page Area и Extended Memory. Размер Roll Area пока можно не менять. 

Согласно документации рекомендации по увеличению обоснованы уже при достижении 85% от максимального объёма областей. Помните: действовать проактивно, а не реактивно.

Extended Memory хранится только в оперативной памяти, а Page Area состоит из области в памяти плюс файл на диске. Сначала используется область памяти, а при достижении предела  данные записываются в файл на диске.

Таким образом, мои рекомендации по новым значениям параметров для общих областей памяти представлены в следующей таблице (рис. 10).

Рис. 10. Рекомендации по настройке областей памяти SAP инстанции.

Это лишь первый шаг настройки. После применения параметров, необходимо дать системе поработать, как я уже писал, пару недель. А далее провести анализ использования буферов и областей памяти в той же ST02. И если это необходимо, рассчитать и запланировать следующий шаг настройки.

Текущий объём общей памяти, сконфигурированной для SAP инстанции, составляет примерно 7 Гб ( если прибавить сюда память для рабочих процессов) (рис. 11). Напоминаю, что просмотреть это можно, перейдя в транзакции ST02 -> "Detail Analysis Menu" -> "Storage".

Рис. 11. Общая память, используемая SAP инстанцией.

После применения параметров этот объём увеличится примерно на 5 Гб. Что в текущей системе приемлемо - оперативной памяти сервера достаточно.

Увеличивать параметры следует аккуратно, не спеша. Общие рекомендации следующие:

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

В данном случае я составил рекомендации. Теперь дело за коллегой. Необходимо аккуратно применил новые параметры к SAP системе. При изменении параметров обязательно понадобится перезагрузка SAP инстанции. 

В продолжении можно прочитать про результаты тюнинга и новые рекомендации по тюнингу.

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

Ошибка ORA-28000: the account is locked

Вы не сталкивались с такой ошибкой? А я вот на днях столкнулся и хочу поделиться своей историей. Может быть эта информация поможет кому-то из вас быстрее разобраться в похожей ситуации.

Однажды, после окончания планового оффлайн бэкапа, система оказалась недоступна для работы. SAP GUI выдавал сообщение о том, что база данных системы недоступна. 

Первая мысль была: "Ну, наверное, по какой-то причине затянулся бэкап". Но переход на уровень операционной системы сервера показал, что база данных запущена, а процессов резервного копирования в операционной системе нет. Правда, со стороны Oracle работают только фоновые служебные процессы и нет ни одного shadow-процесса. 

Вы наверное знаете, что при оффлайн резервной копии базы данных (или как её ещё называют "холодный" бэкап) процессы ABAP инстанции не останавливаются, а остаются работать, потеряв коннект к базе данных. При этом рабочие процессы с настойчивостью и периодичностью пытаются открыть соединение к базе данных. Поэтому, как только база данных становится доступной для соединения, рабочие процессы открывают соединения, а Oracle запускает для каждого рабочего процесса SAP инстанции отдельный shadow-процесс. Подробнее о том, как рабочие процессы SAP системы подключаются к базе данных я описывал в статьях: "Как рабочие процессы SAP соединяются с базой данных Oracle - I" и "Как рабочие процессы SAP соединяются с базой данных Oracle - II". 

Так вот, shadow-процессов Oracle не наблюдалось. Я подключился к базе данных через SQLPlus, используя пользователя SYSTEM. Соединение установилось успешно. На всякий случай перестартовал базу данных. Проверил: shadow-процессов как не было, так и нет. При этом рабочие процессы SAP инстанции в списке процессов операционной системы висели.

Хорошо. Последний рестарт SAP системы был давно, вдруг что-то подглючило на уровне сервера приложений, подумал я. И решил перезапустить сервер приложений. Но скрипты запуска системы выдают: "База данных не запущена, будем запускать. Попытка запуска базы данных заканчивается ошибкой - "база данных недоступна". Стоит отметить, что скрипты запуска SAP системы для проверки доступности базы данных используют утилиту R3trans, входящую в состав SAP Kernel, запуская её с опцией "-d" (рис. 1 и 2).

Рис. 1. Пример успешной проверки соединения с базой данных.

Рис. 2. Пример безуспешной проверки соединения с базой данных.

Проверка переменных окружения пользователей, настроек Oracle client, процесса Listener ничего не дала. 

И только в третий раз просматривая журналы рабочих процессов SAP инстанции (файлы dev_w*), обратил внимание, что код ошибки при попытках коннекта к Oracle отличается от типичного. Когда база данных остановлена, выдаётся код ошибки 1034. 

Рис. 3. Пример кода ошибки соединения с остановленной базой данных.

А тут выдавался код 28000 (рис. 4). 

Рис. 4. Код ошибки при соединении с базой данных в текущем случае.

По коду ошибки удалось выяснить, что ошибка заключается не в недоступности Oracle, а в блокировке пользователя. Как вы уже знаете, из вышеупомянутых статей, что рабочие процессы SAP системы при подключении к Oracle используют пользователя владельца схемы в базе данных. В данном случае это пользователь SAPSR3. Так вот этот пользователь и оказался заблокированным. 

К блокировке пользователя привёл параметр базы данных Oracle - FAILED_LOGIN_ATTEMPTS. Начиная, с версий Oracle 10g значение данного параметра, по умолчанию, равно 10. В предыдущих версиях СУБД по умолчанию стоит значение UNLIMITED. Посмотреть значение в текущей базе данных можно запросом вида:

SQL> select LIMIT from DBA_PROFILES where PROFILE='DEFAULT' AND RESOURCE_NAME='FAILED_LOGIN_ATTEMPTS';

или

SQL> show parameter FAILED_LOGIN_ATTEMPTS;

Как вы помните из моего поста, при соединении с базой данных, до версии Oracle 11g в SAP системе использовался механизм хранения пароля пользователя владельца схемы в отдельной табличке OPS$<USER>.SAPUSER. Так как в момент оффлайн бэкапа база данных недоступна, то рабочий процесс не может получить к ней доступ и прочитать продуктивный пароль пользователя. И как видно из скриншота (рис. 3), каждый раз делается ещё и дополнительная попытка открыть соединение с дефолтным паролем, который зашит в коде ядра. Допускаю, что случилась такая ситуация, что в момент старта базы данных было сделано больше 10 попыток логина к базе данных со стороны SAP системы с этим стандартным паролем (который отличается от продуктивного пароля). В результате этого Oracle автоматически заблокировал пользователя (владельца схемы) и последующие попытки SAP системы присоединиться к базе данных проваливались уже по этой причине, вплоть до моего вмешательства. 

Разрешение ситуации: разблокировка пользователя. Разблокировать пользователя можно в SQLPlus командой вида:

SQL> alter user SAPSR3 account unlock;

После этого рабочие процессы корректно подключаются к базе данных. Для предотвращения возникновения ситуации в будущем -  установка параметра в большее значение, вплоть до UNLIMITED. Сделать это можно SQL-командой вида:

SQL> alter profile default limit FAILED_LOGIN_ATTEMPTS 50;

Со стороны компании SAP ситуация описана в SAP note 951167 - ORA-28000: the account is locked.

P.S. Думаю, что описанная ситуация довольно таки редкая и возможна только в узком круге версий систем SAP и базы данных Oracle. Так как в современных версиях систем пароль хранится уже не в базе, а в файловой системе (подробнее) и попыток попасть в базу данных со стандартным (неверным) паролем не производится. Но в нашей жизни всё бывает и надо быть готовым ко всему.

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

Особенности работы дискового массива HPE 3PAR

В жизни специализироваться только на SAP Basis у меня получается далеко не всегда. Да и лично мне больше интересно строить и администрировать системы на всех уровнях, начиная от аппаратного обеспечения и операционных систем, и заканчивая тонкостями серверов приложений SAP. Поэтому периодически приходится сталкиваться с нюансами работы того или иного оборудования. Всю свою карьеру до текущего момента я тесно работал с оборудованием компании Hewlett Packard. В 2009 году я уже публиковал похожий пост "Особенность работы HP EVA-5000", в котором я описал нюансы работы дискового массива EVA-5K, с которыми столкнулся на практике.

Сегодня расскажу про дисковый массив HPE 3PAR StoreServ. Один из заказчиков выбрал данное решение при переносе своей SAP инфраструктуры. Об этом я упоминал в посте про миграцию. Дисковый массив обладает хорошей производительностью и отказоусточивостью. RAID массив полностью на SSD дисках, конечно же, показывает очень хорошие результаты по времени отклика и количеству IOPS. Но уже дважды сталкиваемся с одной особенностью поведения системы, о которой я и решил рассказать. 

Дисковый массив подключен к серверам через SAN сеть, что является проверенным решением Enterprise уровня. У дискового массива 2 контроллера, в каждом из которых по 6 оптических портов. В реализованном у заказчика решении дублирование оптической сети реализовано через резервирование SAN-коммутаторов. Таким образом, от дискового массива до каждого из вычислительный серверов идёт, как минимум, 4 оптических линка (задействованы не все порты контроллеров). 

На всех аппаратно-программных уровнях SAN сети используется, рекомендуемый (и со стороны 3PAR, и со стороны VMware) multipathing, когда все линки используются по кругу, распределяя нагрузку и повышая производительность.

Пока все линки живы, всё работает просто прекрасно. Но, если хотя бы один линк "погибает", то наблюдается странная картина. Дело в том, что дисковый массив не отключает оптический порт, а просто фиксирует на нём ошибки контроля чётности (CRC error), объявляя порт деградировавшим (рис. 1).

Рис. 1. Пример ошибки оптического порта на HPE 3PAR.

Со стороны метрик производительности дискового массива фиксируется увеличение показателей Service Time даже при незначительной нагрузке. Особенно в плане операций записи (средний график) (рис. 2). Здесь видны колебания до 3 мс, когда обычно (при всех работающих линках) показатели не превышают 0,5 мс.

Рис. 2. Метрики производительности на уровне HPE 3PAR при сбое SAN порта.

Со стороны виртуальной среды VMware видна идентичная картина с метриками производительности дисковой подсистемы (рис. 3). Здесь тёмная линия  это Usage в Кб/сек. А голубая линия - это более интересный показатель - Latency в мс. Стоит отметить, что когда все линки работают без сбоев, то при любой нагрузке, генерируемой всеми вычислительными системами в текущей инфраструктуре, параметр Latency никогда не превышает 0 мс. А тут периодически выстреливает аж до 600 мс.

Рис. 3. Метрики производительности дисковой подсистемы со стороны VMware.

Всё это было бы не так страшно, но реальное приложение, SAP система, ведёт себя очень странно. В своей карьере я ничего подобного не видел. Периодически возникают дикие фризы, когда в очереди диспетчеров SAP инстанций накапливаются рабочие процессы с запросами типа COMMIT и UPDATE (рис. 4). Такая картина висит несколько секунд, иногда до 30-40, потом всё проскакивает и очередь сбрасывается до 5-8 работающих процессов. Между фризами система работает нормально минуту-две.

Рис. 4. Пример зависания SAP системы.

Так как резервное копирование выполняется по той же SAN сети, то время на создание копии также вырастает более, чем в 2 раза (рис. 5).

Рис. 5. Пример увеличения времени резервного копирования базы данных при сбоях SAN порта.

Как я уже говорил, дисковый массив не отключает SAN порты, а крутит линки по кругу. Натыкаясь на сбойные, все операции подвисают (работа фризится), увеличивая задержки на всех уровнях. Затем, когда массив понимает, что через эти линки ничего не отправить, он переключается на рабочие и моментально проводит все запросы (SSD же :) ). Работать очень не комфортно, ощущения как от зубной боли.

Помогает в данном случае, ручное отключение сбойных портов. После чего производительность работы системы нормализуется. Посмотрите на графиках выше точку времени около 12:30. В этот момент порты были отключены (переведены в OFFLINE). Для наглядности детальный график Latency (рис. 6).

Рис. 6. График Latency в момент отключения портов на работающей системе.

Корректное это поведение дискового массива или нет, судить не берусь (но больше склоняюсь, что это ненормально). Причём стоит отметить, что от количества сбойных портов поведение системы не зависит. Один порт с ошибками или половина из всего списка - картина идентична: фризы и зубная боль.

Пока остаётся только учитывать этот факт, при работе с данным оборудованием. Если начались проблемы с производительностью, проверить оптические порты на 3PAR. При наличии сбойных, временно (до того момента, когда инженеры устранят аппаратный сбой) отключить их.

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

Особенности конфигурации файла /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.

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

Когда возникает системный дамп TIME_OUT

Работа пользователей в ABAP-части SAP системы возможна в двух режимах:

• диалоговый режим,
• фоновый режим.

Первый режим является основным. В этом случае пользователь работает с системой в интерактивном режиме, вводя информацию в поля транзакций и получая результаты на экране SAP GUI. За обработку запросов от диалоговых пользователей отвечают отдельные процессы SAP инстанции – диалоговые рабочие процессы (DIA).

Второй режим, фоновый (background), служит для запуска долгих тяжелых отчетов или стандартных периодических заданий для обслуживания SAP системы (задания, собирающие различную статистику, проводящие очистку и т.п.). Фоновые задания не требуют постоянного коннекта пользователя с системой посредством SAP GUI, поэтому пользователь может запланировать задание и выйти из системы. Просмотреть результаты работы задания можно после его окончания через систему спула. За выполнение фоновых заданий в системе отвечает другой вид рабочих процессов - фоновые рабочие процессы (тип BTC).

Количество рабочих процессов для диалоговой и фоновой обработки настраивается через следующие SAP параметры:

• rdisp/wp_no_dia,
• rdisp/wp_no_btc.

Напоминаю, что про параметры SAP системы у меня уже была серия статей (часть 1, часть 2).

Вышеуказанные параметры являются статическими и считываются системой только при старте ABAP инстанции. Количество рабочих процессов в работающей системе можно просмотреть в транзакции SM50.

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

Дело в том, что в любой SAP системе количество диалоговых рабочих процессов инстанции всегда меньше количества пользователей. Так же как и в любой операционной системе количество ядер центрального процессора всегда меньше количества работающих процессов. Поэтому, если найдётся группа упорных пользователей, в которой каждый запустит по тяжёлому долгому отчёту (а то и по 2-3), а отчёты займут на длительный промежуток времени большинство диалоговых рабочих процессов, то остальные пользователи будут "курить в сторонке". Для них система перестанет реагировать на любые шаги диалога, даже, если они работают в лёгких, нересурсоёмких транзакциях. Чтобы пресекать такие ситуации у ABAP инстанции есть параметр rdisp/max_wprun_time. Значение параметра - время в секундах. А если после числа добавить букву M или H, то система воспримет значение, как указанное в минутах или часах (рис. 1).

Рис. 1. Параметр инстанции rdisp/max_wprun_time.

Если диалоговый рабочий процесс работает над одним шагом диалога и интервал времени больше, чем значение, указанное в ограничивающем параметре, то система прервёт выполнение данного шага. В этом случае работающая программа останавливается, диалоговый рабочий процесс освобождается, а в системе генерируется ABAP-дамп с именем TIME_OUT. При этом в разделе "Анализ ошибки" будет подсказка с именем вышеуказанного параметра и его текущего значения в системе (рис. 2).

Рис. 2. Пример системного дампа TIME_OUT.

При долгом ожидании рабочим процессом данных от базы данных также произойдёт сброс и дамп. Для того, чтобы избежать этого, необходимо при обновлении данных периодически вставлять в код программы "COMMIT WORK". После каждой такой команды счётчик обнуляется, хотя шаг диалога продолжает работать на том же рабочем процессе.

Данное ограничение по времени работы одного шага диалога в рабочем процессе можно настраивать на разных инстанциях в рамках одной системы по разному. То есть на одной диалоговой инстанции установить значение в "60M", а на второй и все "3H", если этого требует бизнес. Так же стоит отметить, что параметр динамический, а следовательно может быть изменён во время работы системы в любой момент времени без рестарта ABAP инстанции.

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

Для ориентира следует брать значение по умолчанию, которое равно 10 минутам ("600"). А дальше уже изменять в зависимости от загруженности системы и решаемых задач.

В системах основанных на SAP NetWeaver 7.40 и выше появилась возможность более глубокой настройки данного ограничения, используя следующие 3 параметра:

• rdsip/scheduler/prio_high/max_runtime,
• rdsip/scheduler/prio_normal/max_runtime,
• rdsip/scheduler/prio_low/max_runtime.

Назначение параметров такое же - задание максимального времени работы диалогового рабочего процесса, обрабатывающего запросы разного приоритета (high, normal, low). 

Причём, параметр rdisp/max_wprun_time в системе остался. И при явной его установке перезаписывает значение выше-указанных трёх параметров. Поэтому его рекомендуется из профайлов удалить, а пользоваться новыми параметрами (рис. 3).

Рис. 3. Новые параметры ограничения максимального времени работы одного шага диалога.

Дополнительную информацию по теме можно найти в SAP note 25528 - Configuration of maximum work process runtime - parameter rdisp/max_wprun_time.


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