RE: Zmailer problem

["Luke Galea" <lgalea@bluecatnetworks.com>]

Thanks a lot for your suggestions.. I'll try that out.

Luke Galea 
Software Development
BlueCat Networks
905-762-5225
 

-----Original Message-----
From: Matti Aarnio [mailto:mea@nic.funet.fi] 
Sent: October 8, 2002 11:37 AM
To: Luke Galea
Cc: zmailer@nic.funet.fi
Subject: Re: Zmailer problem

On Tue, Oct 08, 2002 at 11:09:55AM -0400, Luke Galea wrote:
> Ya.. in this specific case that is what we plan on doing. My concern
is
> that our first indication that the queue was piling up was the max
files
> issue.. at one point we couldn't even log in. We were piling messages
up
> in the queue at about 25,000 / hour.. so by the time everyone got in
in
> the morning it was already time to boot from a floppy to disable
zmailer
> at start-up. Some sort of warning mechanism and a max simultaneous
open
> files limit in zmailer would fix this. The warning isn't a problem
> (monitor mailq)... but the open files limit I am unsure of.

  I think the issue is more in the UNIX (Linux) kernel you are using.
  I don't know why, but it seems to overflow the file hash cache, and
  be unable to flush unused ones from it.  Neither does it auto-tune
  this particular system feature...

  Scheduler process uses at most  "ulimit -H -n"  (for bash/sh)
  file descriptors itself, but the system can use a lot more
  internally.



  There increasing the hash-cache size can help you there.

  Oh, also do tech your   updatedb  NOT TO go into POSTOFFICE directory.
  That too appears to trigger this trouble in early morning hours...
  (At my home system anyway, I have kvazillion source directories
   in there, and updatedb has more than once induced death of the
   sshd daemon by running out of openable files... Then I did that
   file-max tuning, below, and the system behaves again.)


  I repeat my suggestion:

    # echo "12000" > /proc/sys/fs/file-max

  Set the value high enough so that your system stays happy.
  Monitor the actual value:

    # cat /proc/sys/fs/file-nr

  You are interested in the middle value.

  That system pseudo-directory has a few other monitor "files" you might
  find interesting to follow.


> As for the multiple SMTP streams.. would setting maxTA to 2 for that
> route accomplish this?

  No.  MaxTA=2 cuts system performance radically down.
  You are looking for  maxTHR=2  in the channel where your virus scanner
  traffic is.  (You have made a channel/host selector pair of its own
for
  that ?  Have you ?)

  Possibly MaxTHR=10  would do also.  (For 10 parallel streams..)
  (presuming the checker can gain speed from it.)

  In the current scheduler.conf  prototype file there is longish
  passage of comments telling about these things:


#  MaxTHR:   ( max processes per thread; default: 1 )
#       This limits the number of parallel transport agents within each
#       thread; that is, using higher value than default ``1'' will
allow
#       running more than one TA for the jobs at the thread.
#
#       Do note that running more than one TA in parallel may also
require
#       lowering OVERFEED value.  (E.g. having a queue of 30 messages
will
#       not benefit from more TAs, unless they all get something to
process.
#       Having OVERFEED per default at 150 will essentially feed whole
queue
#       to one TA, others are not getting any.)


> Thanks for your help.
> 
> Luke Galea 
> Software Development
> BlueCat Networks
> 905-762-5225

  /Matti Aarnio	<mea@nic.funet.fi>
-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi