home *** CD-ROM | disk | FTP | other *** search
- The ServiceMail queueing system -- overview
-
- In normal (non-queing operation) sendmail forks off one 'mesh' process
- to handle each incoming connection. Under light load, this is not
- particularly problematic, but under heavy load it could have the
- effect that all the jobs compete for time, with none of them making
- any real forward progress, slowing down response time dramatically.
- The queueing mechanism is an attempt to alleviate this problem.
- Simply, rather than directing incoming mail to 'mesh', sendmail
- redirects it to 'pdinq', which logs it (if syslog(3) is enabled),
- (optionally) makes an estimate at the priority with which
- it is to be handled (Encoding that in the filename), and
- writes the message to a spooling directory.
- The system continually runs a daemon 'dspd' which watches the
- spool file and dispatches 'mesh' jobs from that directory according to
- certain criteria. In the most basic use, you only need to
- chose how many jobs you want to run concurrently. (The more jobs
- you run, the greater the throughput, obviously, but the more
- the system is tied up. Having two many concurrent jobs running,
- though, will make the system thrash as before. 5 seems like
- a reasonable guess on a SPARC 1+ on a 56 Kb line.)
- dspd wait()s for the jobs to finish and starts more if there are
- any, and basically makes it's best attempt to ensure that not less
- than 'n' jobs are running at any given time, provided that there
- is actually work to do.
- In order to facilitate easy changes, scripts are provided for
- orderly starting and stopping of various functions. divert_mbox
- and revert_mbox divert aliases to temporary files. divert_svc
- and revert_svc divert services at the 'mesh' level, and halt_dequeue
- and restart_dequeue shutdown and startup 'dspd'.
-
-
-
-
-
-
