pete@bally.Bally.COM (Pete "The Invisible Man" Gregory) (07/14/90)
Hi -
I have been struggling with a set of transaction processing programs that
need to run at different priorities, as follows (simple explanation below):
----------
| |
| A |-------
| | |
---------- |
|
|
|
---------- | ---------- ----------
| | ----------> | | | |
| A |----------------> | B | ------> | C |
| | ----------> | | | |
---------- | ---------- ----------
| |
| |
| |
---------- | V
| | | ----------
| A |------- | |
| | |database|
---------- ----------
Explanation: multiple copies of process "A" send transactions to process "B",
which in turn sends transactions to process "C", which updates relational
database (Unify). All messages sent via "messages". Process "A" runs at
"nice" (called in its "C" code) value 15, "B" at nice 10, and "C" at nice 0.
THE PROBLEM IS, even with "C" being at lowest nice (highest priority),
processes "A" are still given runtime by the scheduler so that process
"C" falls behind (messages stack up in its queue).
In this system, processes "A" could receive transactions far faster than
"B" or "C" could process them, so we thought that by giving "C" the highest
priority, this would guarantee that "C" would always be "caught up", and
"C" would in essence 'throttle' the "A" processes. This apparently is
not the case.
'ps' shows that all processes are actually at the 'nice' value specified.
Why is this? Is there some way to guarantee that process "C" will be able
to run all he wants to, before "A" and "B" have a chance to run?
Any hints/ideas/answers will be GREATLY appreciated.
Pete Gregory : uucp: uunet!bally!pete |
Software Engr. : domain: pete@bally.bally.com ---|---
Bally Systems : phone: 702-323-6156 x882 | John 3:16
255 Bell St. : FAX: 702-323-5997 | (think about it!)
Reno, NV 89503 |pj@asd.sgi.com (Paul Jackson) (10/11/90)
In article <3674@zorba.Tynan.COM>, pete@bally.Bally.COM (Pete "The Invisible Man" Gregory) writes: > Explanation: multiple copies of process "A" send transactions to process "B", > which in turn sends transactions to process "C", which updates relational > database (Unify). All messages sent via "messages". Process "A" runs at > "nice" (called in its "C" code) value 15, "B" at nice 10, and "C" at nice 0. > > THE PROBLEM IS, even with "C" being at lowest nice (highest priority), > processes "A" are still given runtime by the scheduler so that process > "C" falls behind (messages stack up in its queue). > > Why is this? Is there some way to guarantee that process "C" will be able > to run all he wants to, before "A" and "B" have a chance to run? What you see is typical of Unix schedulers: if several processes are feeding one process, then the single process gets inadequate time, especially in the case that the single process does more work per message than the feeder processes. The "nice" value helps set the original process priority, but then this priority is adjusted by the amount work each process has done recently in order to determine the actual priority. The harder working process gets penalized. Some systems (e.g. SGI :-)) provide "fixed" scheduling bands which are certain priority levels wherein the relative priority is not adjusted. This allows simpler tuning of your sort of system. Thanks, take care ... Paul Jackson (pj@asd.sgi.com), x1373