Добрый день, уважаемые коллеги.
Время выполнения прогон проводок (транзакция PC00_M99_CIPE, отчет RPCIPE00) выполняется непропорционально количеству табельных номеров.
Скорость обработки табельных постепенно снижается. Примерно на четырехсотом табельном тормоза уже порядка 3 секунд на табельный. Дальше- медленнее и медленнее.

Реализованы
EXIT_RPCIPE00_002 и EXIT_RPCIPE00_004. Ничего криминального в коде не обнаружил. Вложенных циклов нет...
SE30 показывает, что тормоза на методе

Не понял, что с ним не так.
Сломанных стандартных объектов не должно быть совсем нигде.

Уже и не знаю, куда копать.
У кого какие мысли по этому поводу?

Как вариант использовать утилиту RPCS0000 для параллельного выполнения проводок по "пачкам" табельных

За утилитку - спасибо.
Однако хотелось бы разобраться с проблемой.

Знаю, что подобная проблема бывает при работе с ФМ HR_INFOTYPE_OPERATION, он какие-то буфера не чистит за собой .
А если отключить расширения и запустить моделирование - будет так-же плохо или дело именно в расширении ?

Инфотипы читаете в exit-ах? Если да, то очень похоже на накопление данных в буферах HR_INFOTYPE_OPERATION.
При переходе на новый ТН можно сбрасывать этот буффер. Сброс выполняется ФМ HR_PSBUFFER_INITIALIZE, либо HR_INITIALIZE_BUFFER.

Спасибо, мысль интересная. Но, увы, не читаем инфотипов.

Будет так же плохо. Это было одно из первых предположений.
Похоже, что расширения на скорость не влияют.

Тогда можно конечно поставить мессагу в SAP, но ИМХО не поможет
Можно еще посмотреть на базисные всякие параметры , похоже раз фигня у вас происходит на COLLECT_EP у вас в памяти постепенно нарастает внутренняя таблица , которая затем сохранится в таблицу PPOIX , то есть там десятки или сотни тысяч записей и размер ее очень большой . Может не хватать какой-нибудь внутренней памяти или буферов в application server и система занимается ее динамическим выделением или своппингом или еще чем-то таким же интересным .

Об этом я думал. Но как удостовериться в этом?

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

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

Этот collect_ep не выглядит особо сложным. Дело скорее всего в таблицах, которые в нее передаются - ep_sum и ep. collect_ep просто обрабатывает эти таблицы, ничего там больше нет.

Посмотрите размер оперативной памяти на сервере и размер памяти, поглощаемой процессом.
Затем задумайтесь, а нет ли какой-либо корреляции в моменте, когда всё тормозить начинает

кажется он и не может строго пропорционально выполняться, т.к. зависит от глубины перерасчетов и количества разбиений по C0/C1, а это индивидуально в каждом.
Наверное нужно смотреть как-то по однородным группам сотрудников.

Всё равно в среднем время обработки табельного должно быть примерно одинаковым. Ну не может дясяток сплитов C1 затормозить систему на 10 секунд.

Кстати, в моем случае у 95% табельных нет обратных расчетов глубже 1 месяца. И количество сплитов по С1 в среднем по палате сходно.

P.S. Пока еще не продолжал отладку. Если найду причину проблемы - проинформирую общественность.

Была такая проблема у нас.
Мы стали параллелить задания.
базис поставил ноты:
840901 - Parallel buffering and pseudo ascending number assignment
599157 - Number ranges: new buffering method
449030 - FB01: Deactivating number range buffering at interval level
1398444 - Buffering the document number assignment for RF_BELEG

За ноты - спасибо. А они вообще помогли?