HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Set priority of application processes higher than system processes

 
Waikamon
Occasional Contributor

Set priority of application processes higher than system processes

Now I set priority for application processes are higher that system processe. Is there any effect in the future?
8 REPLIES
Duncan Morris
Honored Contributor

Re: Set priority of application processes higher than system processes

Hi,

be very, very careful about setting process priorities of 16 or above. You risk blocking important system processes. Normally, only real time processes would receive such a high priority.

Please read the manual on performance:

http://h71000.www7.hp.com/doc/73final/6491/6491pro_004.html#openvms_sched


extracted from this manual:

3.9.3 Process Priority
When required to select the next process for scheduling, the scheduler examines the priorities assigned to all the processes that are computable and selects the process with the highest priority.

Priorities are numbers from 0 to 31.

Processes assigned a priority of 16 or above receive maximum access to the CPU resource (even over system processes) whenever they are computable. These priorities, therefore, are used for real-time processes.
Wim Van den Wyngaert
Honored Contributor

Re: Set priority of application processes higher than system processes

Examples :

network processes don't get the cpu. Are not able to send/receive packets. You get buffer overflows, retransmissions, timeouts. On your node the application may block because packets are not confirmed.

The system process audit_server doesn't get the cpu. Your application blocks because of mailbox full.

Wim
Wim
Hein van den Heuvel
Honored Contributor

Re: Set priority of application processes higher than system processes

What makes you think that setting a higher priority would actually help?

Cheers,
Hein.
Phil.Howell
Honored Contributor

Re: Set priority of application processes higher than system processes

Are you doing this for idle curiosity, or in an attempt to solve a problem?
In either case, no good will come of it!
Phil
Andy Bustamante
Honored Contributor

Re: Set priority of application processes higher than system processes


Adding to Hein's comment, what behavior are you trying to modify? Is there a performance issue in the your application? If so the Performance Management Manual and the System Manager Manuals can provide details for investigating the cause. http://h71000.www7.hp.com/doc/os82_index.html

Andy

If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net
Waikamon
Occasional Contributor

Re: Set priority of application processes higher than system processes

Thanks a lot for your information. Actually, my customer did it with some reason. And I think it's not a good idea to do like that.

Regards,
WM.
Peter Weaver_1
Frequent Advisor

Re: Set priority of application processes higher than system processes

Based on the process names I see in your listing I think I have a pretty good guess at what your application does (and possibly who wrote it) because I have seen very similar process names on one of the clusters a customer of mine has. Don't go playing with the priorities until you talk to the vendor and listen if they tell you that they know this stuff way better than you do.

If you play with the priorities you might find that you have hot steel getting cold, reheating cold steel costs a lot of money.
John Gillings
Honored Contributor

Re: Set priority of application processes higher than system processes

Waikamon,

Processes with priorities above 16 must have been specifically written to run at real time priority. Sometimes multi process systems depend on different priorities for correct operation, but many would argue this is a poor design, which will often break in SMP environments. There are much better alternatives for proper synchronisation.

The first issue is, if a high priority process gets into a CPU loop, they stay there. On a uniprocessor it's power cycle time. You're on an SMP system, so you *might* be able to manually recover.

Second is many synchronisation mechanisms depend on "busy waiting" at some level. These mechanisms therefore need to equalise priorities before entering the busy wait loop (otherwise you loop forever). The overhead of changing priorities increases the cost of synchronisation, which can counter any perceived advantage of using high priority in the first place. The biggest danger is a low contention resource may not see any contention during testing, but under load, suddenly it's busy, and your system is in a high priority busy wait loop, with no way out!

Third issue is performance. Over priority 16, the process doesn't get any working set adjustment. Unless the application has explicitly set the working set size ($ADJWSL) to an appropriate value, you'll be stuck at WSDEF, which may be inadequate for the process to run. Note that several of your processes have comparatively high page fault counts relative to their CPU time, compared with other processes. This is why a given process will sometimes paradoxically take LONGER to run at high priority than low. In your case it may be that you have sufficient physical memory that they're all soft faults, so the impact may not be immediately obvious, but beware, you may fall into a big performance hole if you ever consume enough memory to turn them into hard faults!

The pagefaults suggest to me that these programs aren't properly written for high priority. Check that it's really the intention of the programmer, if it is, ask why the pagefault count is higher than the working set size! (If you're really serious about real time, the process should fault all its pages into a big enough working set, lock them in and stay there)

I'd suggest you get some performance benchmark, then categorise your processes according to priority - looks like you've got 21, 23 and 29. Change them to 13,14 and 15 (ie: preserve the ranking but put them below 16). Since there are no other processes between, the absolute numbers shouldn't make any difference. Now compare your performance. See if the reduced pagefaulting helps.
A crucible of informative mistakes