Kbase P37854: Unix Process priorities and How Progress uses them
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
6/17/2005 |
|
Status: Unverified
GOAL:
Unix Process priorities and How Progress uses them
FIX:
Unix Process priorities and How Progress uses them
This solution is to provide insight into what the process priority is, how Progress tends to use them, and the possible dangers of interfering with the UNIX delegation of them. The process priority is the fourth field from the left of a ps -ef listing grepped for a particular user. For example:
ps -ef|grep damore
damore 27715 27714 0 09:39:42 ttyp6 0:00 -sh
damore 27732 27731 6 09:40:01 ttyp6 0:00 ps -ef
damore 27696 27695 0 09:26:08 ttyp1 0:00 -sh
damore 27731 27715 1 09:40:01 ttyp6 0:00 grep damore
damore 26877 1 0 Aug 14 ? 0:00 /usr1/73D01/dlc/bin/_mp rosrv rob
In this example, the fourth field is the process priority number. Here you can see that the ps process and the grep process get high priority numbers, which results in less process time from the cpu. The _mprosrv has a very low priority number which results in more processing time by the cpu. Progress typically reserves these low priority numbers for high priority processes, and root typically recieves 0 or 1 as priority.
Typical user processes, such as damore in the example, tend to get higher priority numbers resulting in less cpu time. This can be changed with the UNIX nice command, which is defined in the man page as invoking a command with an altered scheduling priority. It is NOT recommended or supported to use nice for changing Progress process priorities and here is why.
If a user has "niced" their process priority, there can be instances where a contention situation can be created, and the consequences can result in a significant performance hit, among other things. For example, a user logs in with a "niced" user priority and receives a very low process priority number. The user then acquires a latch in shared memory. Because this user now has a low priority number, thus more cpu time, they are more likely to get swapped out as to avoid
"hogging" of the cpu. Meanwhile, an important Progress process such as an APW is waiting on that same latch but can't acquire it because the user holding it has been swapped out. This means that two processes are in contention for the same latch, and in this case a waiting APW means instant i/o and performance degradation. Latch contention was a particular problem in earlier versions of 6, and this kind of situation can only make things worse.
Basically, Progress reserves the lower priority numbers and higher cpu time for more important processes and utilities. This is by design and should NEVER be manipulated, especially when using the UNIX nice command. For more information on nice or the process priority number, consult your operating system documentation or the the operating system man page on each.