Priority increases automatically

[Shankar Bose]

In a clustered OpenVMS 8.2 multiple CPU ALPHA environments the priority of a process which is triggered with a base priority of 8 creeps up to 63 within few days.
Though the system is currently not facing any problem due to this, but a process that has been a time slot based one moves to real time is not welcomed, also it is running with priority higher than SWAPPER, which is running at priority 27.
Is there any way of restriction it?

[Wim Van den Wyngaert]

Start in batch :

$b:
$ set proc/id=xxx/prio=8
$ wait 00:01
$ goto b

But why is it happenning ?

Wim

[Hoff]

OpenVMS should not and does not normally increase priority from timeshare to realtime.

This is almost certainly local code, or local commands, or a local user that's responsible; a trigger within the local environment. (If this were a general error in OpenVMS, there would likely be more reports of this around.)

Enable system service auditing and use it to find out which process here is calling $setpri. The altpri privilege can be audited. Use "set audit /enable=privilege=success=altpri", IIRC. (Somewhat surprisingly, there's no way to directly audit $setpri calls. Weird. HP should consider an enhancement there.)

On no evidence, I would review the code of the image itself, and whatever code you might have around that calls the $setpri system service.

[Michael Moroney]

Even SWAPPER running at priority of 27 seems odd. I thought its priority was fixed at 16.

[Shankar Bose]

We are trying to trace why it is happening. The mentioned process is a server process and on client request it starts threads to serve it. There may be some ripple affect changing the priority of the process. There are around 90 application processes running with priority 7, 8. We could see that other process also keeps changing priorities but they are within time base range. I will start doing the audit, and see whether that helps.

[Jon Pinkley]

What are you using to view the process priority?

Can you paste the output here?

[Shankar Bose]

$ SH PROCESS/ID=nnnnnnn/CONTI
and watch the field Cur/base priority in the display.

[Wim Van den Wyngaert]

That are 2 fields. Is it cur or base going to 63 ?

[Shankar Bose]

Both are drifting

[Jon Pinkley]

And the base priority is increasing?

If so, as Hoff said, it is almost certainly not something that is part of stock standard VMS that is modifying it.

The only thing the VMS schedular modifies is the current priority, and that only up to base + PRI$_TICOM (boost of 6, which is immediately dropped by one when it is scheduled). And that will never promote the current priority above 15 (it will not move it into the realtime priorities).

So what other software do you have running? Any "fair share" priority adjusters?

RE:"Both are drifting"

When the base is in the realtime range, the current priority should be the same as the base, i.e. VMS shouldn't be applying dynamic priority adjustments to real time processes. Is that consistent with what you see?

Jon