Workprocess in PRIV mode

[Former Member]

Hello,

We have production system on windows platform.My application server has 15 UPD and 5 BGD work processes.

Whenever i try to run a big report 2 to 3 work processes go in PRIVATE mode and they are in "HOLD" status.

I increased the Heap Memory and Program Buffer size, but the problem still exists..

Please guide on this issue as early as possible..

Thanks & Regards,

Ravindra

[JPReyes · Accepted solution]

Hi Ravindra,

15 Update processes is quite a lot... I'll reduce the ammount of processes so the memory is better distributed between the processes.

A process goes to PRIV mode when all memory is allocated and process is waiting for memory to be realeased...

Check

abap/heap_area_dia

abap/heap_area_total

abap/buffersize

PHYS_MEMSIZE

Hope this help!

Juan

[Former Member · Accepted solution]

Hello,

I have reduced the number of work processes and also increased the mentioned parameters,but this does not resolve the issue.

Regards,

Ravindra

[Former Member · Accepted solution]

sorry, but this answer is wrong.

A work process runs in Priv Mode, when the transaction currently processed allocates more than

em/address_space_MB - em/global_area_MB

of memory. This portion of an ABAPs memory is shared memory and can be accessed by every work process.

The default values for these two parameters are depending on the platform (Windows 32 Bit 512 MB, Window 64 Bit 4 GB).

If the transactions needs more memory it is allocated as Heap memory in this process. As Heap Memory is not shared Memory the transaction cannot be rolled out and rescheduled on a different work process when the user is inactive.

it stays on the work process it is currently working on which therefore get's reserved for this transaction in other words the work process is private to the transaction.

The work process will leave the Priv Mode and will be usable by other transactions when the transaction allocating the memory is closed.

abap/heap_area_* will limit the amount of memory allocatable on heap. Setting them to very low values might help you to control overall resource consumption, but the transactions will fail when they need more memory.

[cwcheong]

In some cases, due to application's variant and range of selection.

1. Pls check in sm50 during the long running process which table / transaction is causing the issue

2. some cases. could be program bugs that causing enless loop.

3. reduce program variant, period, range. would help to resolve this issue. (assumed the issue is specific to some transaction or module)

Hope it helps.

Steven