permanent higher priority and the ramifications

[David Jenkins]

I have an application that logs into a heavily used 9000 running 10.20 and I'm trying to have the user IDs that this application uses moved to a slightly higher priority than the other interactive users (It does relatively time sensitive processing). The UNIX support team doesn't seem to want to pursue the matter so I'm trying to find the answer myself.

My questions:
How can the priority be set permanently for a particular login so that it is slightly better than a normal user?

What potential ramifications are there? (Could it hog system resources excessively, etc.?)

Thanks in advance,
David Jenkins

[Paula J Frazer-Campbell]

Hi David

If the Unix support team do not wish to persue your request I would suggest that they have reasons for not placing your job at a highter priority.

The ramifications are endless, but the main one I can see is that it would push jobs that the support team see are more important or equal status down.

The Unix team see the bigger picture of all that the server has to do.

I would suggest that you document your request listing all the reasons that you believe that your job should be given highter priority and present it to them - then await their answer.


HTH

Paula

[Rob Smith]

Why dont you try putting "renice --n 5 $$" into the persons .profile. As far as system ramifications it is hard to say without seeing what is actually on the box but I would be very careful and not increase each user's priorities too much.

Hope this helps,
Rob

[David Jenkins]

The only fear the Unix team had was that the application could hog resources to the point that the system doesn't respond, while I realize it might be possible, it seems very unlikely. Let me explain the situation in more detail:
we are using Rumba to access an application on the Unix box and traverse through the same screens any user does. It stops at various points during the process to make sure the system has taken all the input correctly and then continues. I understand many of possible problems, but considering that this application is generating nearly half the revenue for this division, I've been tasked with finding this out by my superiors. Unfortunately the support team has even admitted to being new to HP-UX, I think they're reaction was based more on not-knowing what would happen rather than knowing what could happen.

My understanding of the processing queue is that priority degrades as usage increases and upgrades as usage decreases (upto the priority threshhold set by the system), making it so that higher priority processes do get more process time on average, but they can't completely lock out lower priority processes either.... Please correct me if I'm wrong in this assumption.

Are root privledges required to have renice run in the .profile?

Thank You,
David Jenkins

Between a rock and a meat grinder.

[Tim Malnati]

The first place I would look is at your 'time sensitive processing'. More often than not this can be corrected at the applications level without the need of changing priority. And a lot depends on how you view the term also. Are you talking about a process that must start at a particular time or one that needs to finish by a particular time instead? Will indexing improve it or can you accumulate data in a work file prior to running it? Almost all application processes can be multi-threaded. Maybe if you give us a little more insight into what and why, we may be able to give better guidance as to how.

[Bill Hassell]

It all depends but for a fairly broad rnage of processes, adjusting specific program priorities is not going hang the system. The only priority that can do this is a realtime priority and only root can make this change.

Priorities and response times don't necessarily follow each other. For simple compute-bound programs, a higher priority program will get more CPU cycles over time but for I/O programs (disk, terminal, LAN), it is difficult to predict a performance increase.

When a process makes an I/O request, it is put to sleep waiting for the I/O to complete. The priority is adjusted to a better level because it is no longer using CPU cycles and therefore desirable as a process to reinstate quickly once the I/O is complete.

The HP-UX priority scheduler is very complex and tries to maximize CPU usage for processes while providing a fair share to all competing processes.

As with all benchmarks, you'll need a repeatable circumstances to measure the effectiveness of negative values for nice. It should be noted that only root can create a higher priority process..ordinary users can only degrade (make nicer) their processes.

[Jeff Barber]

Another suggestion would be to renice "normal" users *below* the Rumba users in priority. That way the special users will run at normal priority and then there shouldn't be any risk of contention with the system processes.

Maybe, if this is a really serious, revenue driven requirement that it might be worth looking at the Process Resource Manager (PRM) product to guarantee a minimum CPU share for your special users.