This software is owned by The university of California, Irvine,
and is not distributed under
any version of the GPL. GPL is a fine series of licenses, but the owners of the software need it to be distributed under these terms.
IQS is essentially two things:
IQS is an implicit queuing system, in the sense that users do not have to
explicitly submit jobs to a queue with commands like qsub or llsubmit.
IQS is a sort of portable ultrabatch scheduling class, in the sense that
processes are still managed by your operating system's usual scheduler, but
IQS adds an additional layer of scheduling overtop of that, which is
extremely coarse-grained (subject to how you configure IQS).
How IQS functions:
IQS just lives in the background, polling /proc from time to time. If in
doing so, IQS notices a program (PID) that is taking a large amount of CPU in
a given time interval, IQS will add that PID to a round robin list of PID's
to manage.
These selected PID's of high-CPU programs are simply kill -STOP'd
and kill -CONT'd over and over, to achieve the effect of only a user
defined number of CPU hungry processes running at a time.
If you have processes that are taking up too much virtual memory, then
IQS is not the entire solution for you, and possibly not a part of your
solution at all. It may however be a part of your solution. This
is because IQS does not pull stopped processes out of VM - it only pauses
them.
Paths of note:
/var/IQS - this directory is created automatically by IQS if it does not
exist
/var/IQS/managed - this file is a list of PID's being managed by
IQS, one PID per line.
/var/IQS/exempt-users - this file is a list of usernames whose
processes will never be managed by IQS, one username per line.
/var/IQS/exempt-programs - this file is a list of programs, one
per line, that will never be managed by IQS. It uses a simple substring
search, and the lines will be truncated if they are more than 100
characters long. Note that once you enable this for a program, if your
users figure out that this has been done, they can be ornery by changing
their program's argv somehow to look like one of the exempt programs!
Relevant signals (alphabetically):
SIGCONT- used internally by IQS to resume a process
SIGHUP- sent by an administator to IQS, to make IQS reread its list of
managed PID's from /var/IQS/managed. Using this
facility and a text editor, you can easily add or remove a PID from IQS's
management.
SIGINT- sent by an administrator to IQS, to make IQS tell all
managed processes to resume, and IQS then exits. Because the list of
managed PID's is left in /var/IQS/managed, you can conveniently
stop and restart IQS, without IQS losing track of which PID's it should be
managing.
SIGSTOP - used internally by IQS to pause a process
SIGTERM - same as SIGINT.
Command line options:
-v
Run verbosely
-n x
Run a maximum of x IQS-managed processes concurrently
Here's an xload -update 1 graph showing what impact IQS has on
CPU load. More specifically, this graph was made as I fired up 5:
while : ; do : ; done &
processes, to intentionally pound a Solaris system's single CPU. As you
can see, the load starts at zero, zooms up to 4, and then slowly tapers
back down to a steady 1. This is because it takes IQS a while to notice
new CPU hungry processes, and I started all five of them at nearly the same
moment. The load comes down to one, because I started IQS with -n 1,
meaning "run only one process concurrently". The unusual slope of this
curve, I believe, is not because of IQS or the while loops, but likely due
to an oddity of the Solaris kernel load computation.
Kinds of interactive processes that IQS tends to try to manage that it probably shouldn't in many cases
Web browsers tend to rack up lots of CPU fast. If you want your users to be able to use a browser on
an IQS machine, you'd probably better make exceptions for them.
Same goes for X servers, like XFree86 and xorg.
Supported Operating Systems:
I originally needed IQS for a Solaris system, but set out to write
it on a linux system because that's what I had at home, but back then
the relevant Linux library had a nasty memory leak, so I scrapped the
linux version (for the time being) and moved right to Solaris, after
which the memory leak disappeared. IOW, there is no Linux
version at this time, though I wouldn't be surprised if we want one
someday soon.
About anything with an even somewhat standard unix-style /proc should work fine.
This is known to include Solaris, IRIX and Tru64.
AIX /proc is also supported. While it has kind of a nice /proc
interface (It uses file I/O where most unixes use an ioctl passing
the address of a struct), it is far from a standard unix /proc.
