Introduction
XI server uses 99% CPU cycles especially while executing a BPM scenario / deploying etc. This makes the server hang for a while (even after the BPM scenario ends) and gives timeout for other services running on the server e.g. CVS etc and makes anyone unworkable. The blog is a very simple solution.
Problem
When we deploy / run BPM usually a process called disp+work takes 99% CPU time. If we are working on the server, you might probably prefer to take a coffee and come back. Since it makes the system busy with disp+work running on back ground, no foreground process is given preference. You must manually set the priority to high for any foreground system you are working.
Solution
I was doing this for a very long time until recently I thought of doing the reverse. – set low priority for disp+work process.
This is the key idea which solved this big problem (may be for me). But there is a small round about trick. You cannot change the priority of disp+work even from an administrative windows account. You can only do it from the user, SAPService<SID> or the account that belongs the the SAP local admin group. So, run the task manager using ‘Run As’ and give this user and change the priority to all disp+work to low. By default the priority for disp+work will be normal.
Effect
Though this is a very simple idea, this actually gives you an illusion and makes you to feel that the server is working faster. This ensures that System idle process always takes more than 50% CPU cycles. i.e, there are always free CPU cycles for executing any foreground process.
This also, enables you to give preference to foreground processes and the server processes your foreground requests sooner in spite of busy service running.
Note: I can’t see the XI server running on linux hanging when a BPM is executed / some deployment happens.
