Best way to measure sendmail queue depth?

[Stephen Swaney]

> -----Original Message-----
> From: mailscanner-bounces at lists.mailscanner.info [mailto:mailscanner-
> bounces at lists.mailscanner.info] On Behalf Of Richard Frovarp
> Sent: Monday, June 19, 2006 11:41 AM
> To: MailScanner discussion
> Subject: Re: Best way to measure sendmail queue depth?
> 
> Stephen Swaney wrote:
> 
> >>-----Original Message-----
> >>From: mailscanner-bounces at lists.mailscanner.info [mailto:mailscanner-
> >>bounces at lists.mailscanner.info] On Behalf Of campbell at cnpapers.com
> >>Sent: Friday, June 16, 2006 7:02 PM
> >>To: MailScanner discussion
> >>Subject: Re: Best way to measure sendmail queue depth?
> >>
> >>Quoting "Furnish, Trever G" <TGFurnish at herffjones.com>:
> >>
> >>
> >>
> >>>I've been checking sendmail inbound queue depth using a simple readdir
> >>>and dividing the number of entries by two.  This is checked every five
> >>>minutes by Nagios with a 10-second timeout -- because of the timeout
> and
> >>>the frequency with which I want to do the check, I can't just use, for
> >>>example:
> >>>
> >>>    mailq |head -1
> >>>
> >>>...because under heavy flow conditions the mailq command takes WAY too
> >>>long to parse the entire set of queue files and generates too much
> load.
> >>>
> >>>I always realized dividing the number of files in the queue by two was
> >>>only a rough guess, but I didn't realize there could be so much
> >>>disparity between that number and the number of messages listed by
> >>>mailq.  With mailq reporting 6 messages in the inbound queue, the
> >>>directory actually contains 477 files!
> >>>
> >>>
> >>The multitude of non-paired files are probably DATA files (df) of some
> >>incomplete connections. You can probably delete all of these, but I
> would
> >>check
> >>the times on them first. This is more than likely an attempt to clog up
> >>your MTA.
> >>
> >>You could use a script with 'find' telling you which ones are older than
> a
> >>certain time period (one day should be very safe, one hour is probably
> >>OK), and
> >>delete them. Just a simple one-liner in your cron. Other than that, I'm
> >>sure
> >>there are sendmail options that would take care of this too, but they
> >>don't jump
> >>to mind right now, probably 'timeout_' options are the easiest to do.
> >>
> >>
> >>>Mailq's result seems to match the count of files starting with a
> >>>lowercase "q".  I also have about the same number of files starting
> with
> >>>an uppercase "Q".  The rest of the files are df files, most of them
> >>>without any corresponding q file.
> >>>
> >>>
> >>The 'Qf' files, I believe, are non-deliverable files, those that can't
> be
> >>delivered even to postmaster. They are renamed qf files.
> >>
> >>Hope this is accurate.
> >>
> >>Steve Campbell
> >>
> >>
> >>
> >>>Any idea what's going on?  Previously I expected to find files that
> >>>started with qf, df, xf, and tf (not Q), and to always have pairs of
> >>>files.  Obviously my expectation was pretty far off. :-)
> >>>
> >>>--
> >>>
> >>>
> >
> >To find "orphaned" files from dropped or munged MTA connections (and only
> >for sendmail systems) probably the command you want to use first is:
> >
> >	find /var/spool/mqueue.in -mmin +120 -exec ls -l {} \; | more
> >
> >After examining the output and verifying that the all the files listed
> are
> >more than 2 hours old, then run:
> >
> >	find /var/spool/mqueue.in -mmin +120 -exec /bin/rm {} \;
> >
> >Be careful. Typos can wipe out your operating system :(
> >
> >If you continue to see a LOT of these orphaned files, check that:
> >
> >	Lock Type =
> >
> >In MailScanner .conf is set correctly for your version of sendmail (hint
> >search the MailScanner archives).
> >
> >A good weekend to all!
> >
> >Steve
> >
> >Stephen Swaney
> >Fort Systems Ltd.
> >stephen.swaney at fsl.com
> >www.fsl.com
> >
> >
> >
> I would go for a time greater that a mere 2 hours. We have had systems
> trying to catch up to a spike for almost and entire day. If the check is
> just 120 minutes, it would help the system catch up quicker, but it
> would delete a lot of mail as well. We have been addressing the
> performance issues and will be rotating in an additional MailScanner
> machine before the school year starts up again, to try to alleviate such
> backlogs.
> 

Absolutely. That's why I recommend running:

find /var/spool/mqueue.in -mmin +120 -exec ls -l {} \; | more

Examine the output and make sure the files are all old before you blow
things away :) 

And of course you can always increase +12 to whatever you are comfortable
with.

Steve

Stephen Swaney
Fort Systems Ltd.
stephen.swaney at fsl.com
www.fsl.com