With a total of 100 mailbox (4gb) has more then 20mb, max is 150mb was running fine.
That's still 150 MB that has to be read end-to-end every time an IMAP and webmail process need to get the headers, and re-read every time a new msg comes in while the webmail process has it open (at least it used to be like that. I could never use webmail because while I was looking at headers and selecting msgs to delete, and then delete failed saying "something has changed...." how freaking useless).
Daily defragmentaion is scheduled. On friday I stopped everything on box and defrag the disks. But it didn't helped.
good
Spool is on different partition and different disk with imail.
good
I don't know if smtpd is receiving when I look at netstat. Probably not.
ip.ad.re.ss:25
means SMTPD server session is listening or established.
SMTP client will use random ports >1024
smtpd using %50 cpu (avg). will look at, disk io later.
sounds like a lot, but consistent with your "SMTPD deaf" problem. If all TCP sessions are consumed, then addition SMTP clients will get "connection refused", ie, Imail becomes deaf.
I have changed the relay to not to relay 2 hours ago. And no problems.
ok. Sand and agree (weird), that it was a bad move, non sequitur.
A matter of auth uses lots of cpu?
IF you look at SMTPD session in Imail og, you will see the SMTPD AUTH is a different process ID. Meaning there is a process switch, and there is some crypto calculation (CPU) to en/decrypt SMTP AUTH. But I don't think that your problem.
SSL on Webmail HTTPS session will be MUCH heavier for CPU than SMTP AUTH.
Also smtp sending to gateway for outgoing emails.
that's good. For that qty of mailboxes, you could probably reject 50+% of incoming by IMGate as spam.
When Imail goes deaf and you have 50 SMTPD sessions, I think the problem is that these SMTPD sessions are being abnormally held open too long, and I still suspect the filesystem in some manner.
You need to look a that Imail log to see what Imail SMPT/D is doing.
Maybe in peak hours, your machine is just pooping out, "hitting the wall" and can't back away without a reboot.
btw, I just worked with an Imail/IMGate client, who "thought" his Imail machine was working ok, but in peak hours, I could see that IMGate could not send to it, his machine was refusing connections, just like yours. He built a new, much more powerful machine, and now it handles the load well.
Len
_____________________________________________________________________ http://MenAndMice.com/DNS-training: New York; Seattle; Chicago IMGate.MEIway.com: anti-spam gateway, effective on 1000's of sites, free
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
