[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Zmailer problem
Thanks a lot for your suggestions.. I'll try that out.
From: Matti Aarnio [mailto:email@example.com]
Sent: October 8, 2002 11:37 AM
To: Luke Galea
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
> that our first indication that the queue was piling up was the max
> issue.. at one point we couldn't even log in. We were piling messages
> in the queue at about 25,000 / hour.. so by the time everyone got in
> the morning it was already time to boot from a floppy to disable
> at start-up. Some sort of warning mechanism and a max simultaneous
> 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
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
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
# running more than one TA for the jobs at the thread.
# Do note that running more than one TA in parallel may also
# lowering OVERFEED value. (E.g. having a queue of 30 messages
# not benefit from more TAs, unless they all get something to
# Having OVERFEED per default at 150 will essentially feed whole
# to one TA, others are not getting any.)
> Thanks for your help.
> Luke Galea
> Software Development
> BlueCat Networks
/Matti Aarnio <firstname.lastname@example.org>
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to email@example.com