Работа пользователей в 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.
Автор:
Шиболов Вячеслав Анатольевич
