Привет, мастера hcm.

Исходные данные
Сабж при запуске на рабочих объёмах жутко загрузил систему.

1. железо достаточное (sf8000)
2. В st05
sql:

17:04:40.192 4.169 CL_SQL_RESULT_SET=============CP FETCH 11 21.666 1
17:04:27.346 2.373 CL_SQL_RESULT_SET=============CP FETCH 11 21.666 1
17:04:29.522 2.255 CL_SQL_RESULT_SET=============CP FETCH 11 21.666 1
17:04:27.103 1.508 SAPLOM_ICONS T777O FETCH 171 1.857 452
17:05:05.099 1.488 SAPLHRMS_BIW_PTDW ROOSOURCE REEXEC 12 1 1
17:05:07.019 1.432 SAPDBPNP PA0001 FETCH 213 169 1
17:05:03.263 1.379 SAPDBPNP PA0001 FETCH 213 169 1
17:05:00.158 1.372 SAPFP50P PA2001 FETCH 113 132 0
17:05:05.831 1.358 SAPLRHAS HRP1001 FETCH 101 315 0
17:05:02.447 1.356 SAPLHRAC PA0294 FETCH 47 40 0
17:05:01.212 1.332 SAPDBPNP PA0001 FETCH 213 169 1
17:05:03.502 1.293 SAPLRHAS HRP1001 FETCH 101 315 0
17:05:02.212 1.238 SAPLRHDB HRP1000 FETCH 174 698 1
17:05:00.164 1.237 SAPFP50P PA0008 FETCH 1 56 1
.......
по буферам:

17:06:32.244 5.848 SAPLSSQ0ACC D345T LOAD 0 0 256
17:05:00.406 1.740 SAPDBPNP T777D FETCH 0 1.076 64
17:05:00.361 1.022 CL_EXITHANDLER================CP SXS_INTER FETCH 0 1 0
17:05:00.156 745 CL_EXITHANDLER================CP SXS_INTER FETCH 0 1 0
17:05:21.981 450 SAPLRHAS T777E FETCH 0 13 64
17:05:19.804 394 SAPLRHAS T777E FETCH 0 13 64
17:05:11.153 383 SAPLRHAS T777E FETCH 0 13 64
17:05:18.637 380 SAPLRHAS T777E FETCH 0 13 64
17:05:21.860 362 SAPLRHAS T777E FETCH 0 13 64
17:05:13.747 359 SAPLRHAS T777E FETCH 0 13 64
17:05:17.557 349 SAPLRHAS T777E FETCH 0 13 64
17:05:17.400 344 SAPLRHAS T777E FETCH 0 13 64
17:05:02.392 343 SAPLRHAS T777E FETCH 0 13 64
17:05:20.640 343 SAPLRHAS T777E FETCH 0 13 64
17:05:12.964 341 SAPLRHAS T777E FETCH 0 13 64
.....
-----------------
те сотни тысяч обращений к базе на один табельный! это что ж за алгоритм такой?
причем поначалу было нормально, но потом что-то "донастроили" и получи базис подарочек

зы. "в базе" теряется 30% времени, остальное колбасит в буферах (своп чист)
куда копать?
каждую минуту запускается SAPLHRMS_BIW_PTDW ROOSOURCE REEXEC - отрубить можно?

Этот отчет формирует право на отсутствия. Код там жуть сколько однотипных действий выполняет для каждого дня периода на который формирует отпуск. Он изначально тормознутый и помочь может только запуск его с параметрами, которые уменьшают количество анализируемых табельных номеров. Если нужно перебрать всю базу, то желательно разбить всю выборку на несколько частей и запустить их параллельными задачами...

П.С. Если произошло существенное замедление по сравнению с тем что было, то возможно добавили свой код через расширения HRPTIM03 в cmod.

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

Проблема в том, что четких критериев какие табельные подходят а какие нет отдельно от системы начисления права на отсутствия нет. Поэтому и приходится в большинстве случаев перебирать всех.

Была нота в которой рекомендовалось построить индекс дополнительный по таблице HRP1001 при проблемах с производительностью в HR вообще . Нам помогало с пенсионкой , но там понятно - по связям ВУТ работают . Но может и вас есть отпуск за ВУТ и какая-нибудь хитрая реализация его расчета

создал индекс, но не помогло.
жрет-то всё fetch - 10 тыс по одному юзеру

но в чем сакральный смысл обхода всей оргструктуры для каждого табельного за каждый (из 365) день будущего?!
а вдруг что-то изменилось через через два месяца в будущем

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

Можно еще кстати распараллелить работу отчета через программу RPCS0000

Добрый день!

Если произошло серъезное замедление работы, то рискну предположить что изменили настройку генерации с ежемесячной, ежегодной (или любой другой) на ежедневную. Последняя даёт самый точный результат при подсчете и формировании права, но приводит к резкому увеличению времени работы и поглащению ресурсов.
Лучше всего в данной ситуации распараллелить работу отчета с помощью программы RPCS0000, как уже писали.
Либо воспользоваться функционалом системных событий. Последний будет запускать отчёт RPTQTA00 только для тех табельных и дат для которых это надо, но без Z тут никак не обойтись. Обычно абапится BADI HRPAD00INFTY метод IN_UPADTE.

могу предположить ещё 2 потенциально узких места:
1. бывает, что генерацию отпуска настраивают в зависимости от стажа (тем более что вон звоночек - читается 294 ит), а это ресурсоёмкий процесс, тем более если ежедневная генерация - для каждого дня оно запускает расчёт стажа
2. Структурные полномочия, если криво настроены/неоптимально, могут весьма затруднить выборку. Особенно при использовании ФМников подвыбирающих ИТ. Если выборка через ЛБД - проверка структурных происходит один раз, если + фмники - ну на каждый соответственно ещё по разу.