Best way to measure sendmail queue depth?

[Richard Frovarp]

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.

Richard