Когда возникает системный дамп 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.


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