Process priority of 0, who did it?

[Mike R Smith]

OpenVMS Alphaserver running 8.3. In working through some perfomance issues we discovered some processes on the system with priority set to 0 as seen by the $show sys command.

I have been questioned as to whether VMS is doing this. I have checked sysuaf records and I could not find a single account with prio: set to 0.


One interesting thing, sda showed initial proc priority of 4 but a $ show proc/cont/id showed a cur/base of 5/0 for the same process.


I have not found any dcl code that is being run by at least the account I am checking now that is setting this.

Per HP, VMS would not just do this to a process, it would bump up priority to get runtime for a process but not bump it down to 0.

Has anyone out there seen anything like this? Any idea why the show proc and sda are showing different base priorities? All help is appreciated.

[Hoff]

"Some processes?" Um, some details, please? Your applications and processes? System processes? What's changed here?

The HP representative is referring to the process scheduling scheme used for timesharing-priority processes and the inherent priority boosts for I/O-heavy application processes, and which is largely irrelevant here. That's how the process goes from the base or lower priority to a higher priority; it's how priorities get boosted. Not dropped.

The usual trigger is an errant process creation call within the application creation code for the particular process. Somebody forgot to initialize an argument on $creprc or such. If these are your local applications, check the creation.

OpenVMS Security Auditing can sometimes help capture details of these cases.

The secondary trigger for these is a user (sharing the UIC with the target or with sufficient privileges to access the target process context) issuing a SET PROCESS /PRIORITY command.

[Jan van den Ende]

Mike,

another possibility which is not yet excluded by your supplied info: if those are BATCH processes, the BASE_PRIO for the queue in which they are executed may be 0...

SYSUAF prio does NOT apply to batch jobs, queue base_prio takes that role instead.

fwiw

Proost.

Have one on me.

jpe

[Mike R Smith]

Thanks all for replies so far. Let me attempt to answer them.

some processes - it is a mixture, main app runs on cache database but i have seen regular user type accounts as well as operator account type processes with priority at 0 we have seen this with batch and interactive processes

One of the other admins checked security records and found nothing.

We had checked the batch queues and none had a base_prio of 0. I checked both the startup
file and the running batch queues just now anyway.


If it is a process creation issue, what is sda referring to when it shows an initial process priority of 4? Hoff would you be able to clarify that part? My initial thought is that if the $creprc were setting it, sda would have an initial proc priority of 0, not 4??

[Hoff]

Current and base 5 and 0 respectively is indicative of a creation request of priority 0 or a $setpri or SET PROCESS /PRIORITY to zero or a batch base priority of zero; that's the $creprc or RUN /DETACH base priority I was referring to (and the queue priority boost (mentioned else-thread, too), and the process priority boost (to 5) that the HP rep was referring to. This is the difference between JPI$_PRI and JPI$_AUTHPRI, within $getjpi.

I've (also) seen this stuff with wacky load balancing tools (that try to second-guess the scheduler) and with "helpful" users tossing $setpri or SET PROCESS /PRIORITY commands around the system.

One wrinkle with all this with the current priority: the $getjpi call can itself or other queries based on $getjpi can give the target process current priority a (usually temporary) boost. These will not affect the base priority.

You will want to determine the patterns of processes (and threads) involved; details here are not sufficiently specific with the processes involved for me to determine if this is a general problem with the box, or if this is specific to your own local users and local and installed layered products.

If OPCOM or CONFIGURE or ERRFMT or other such OpenVMS system processes are involved, this is a bigger issue than if some Cache server processes, or local processes or threads or such are tangled. This sort of detail can lead you in a particular direction, as it's (more) likely that a priority zero on a user-created process is something specific to $creprc, while OPCOM or such at priority zero tends to point toward a "helpful" user or a "helpful" load-balancing application.

To watch for future priority changes here, use the SET AUDIT command, and then the ANALYZE /AUDIT command. Confirm and enable if necessary security auditing of the PRIVILEGES and specifically for use of GROUP, WORLD and ALTPRI privileges, confirm and enable if needed ALL types of LOGIN auditing, and confirm and enable if needed PROCESS-level auditing for SETPRI requests. HELP SET PRIORITY /ENABLE for details.

[Graham Burley]

A quick Google throws up an alert re Cache and priorities:

http://www.intersystems.com/support/cflash/2004announce.html

See "March 3, 2004 - HIGH^%PRIO on OpenVMS (Alert Superseded)"

[Hoff]

Graham's almost certainly got it.

Cache blew the $creprc call, as described above.

[Mike R Smith]

Thanks Graham, we did know about that Cache issue. It was fixed in a later version per some of the old timers here.

This is one of those cases where you have to not only prove it is not the O/S, you have to find the real problem even if it is in another area.

A conference call was just held and apparently the application has certain tables with values that can change the process priority. I am following up on that now.

[Mike R Smith]

We have discovered by walking through with a user that some section of application code is setting process priority down to 0. We actually monitored as the user walked through each step and watched the priority decrease as the user stepped into the code and increase as the user stepped out of the code. Thanks for all the comments.

Hoff, thanks for the information on the priority and process creation.

[Mike R Smith]

Issue determined to be in the application code itself, not the operating system.