Mail Server Performance
I've had a Postfix/Dovecot installation running for a couple of months now and generally I'm very happy with everything.
The only issue I'm running into is performance at peak times, with roughly a hundred messages sitting in the queue for ten to fifteen minutes waiting for local delivery. Loads, according to "sar", are averaging around 0.25 (just eyeballing it), with peaks never going over 0.50 and plenty (outside of peak times) at or very close to 0.00. If I'm not mistaken, this is just fine, especially on a machine with eight cores.
However, the I/O rate hovers consistently between about 1500 and 1900 during peak times, so I suspect that's where the problem lies.
I'm happy with the overall configuration of the server, so I'm not really looking for suggestions to disable this or fine-tune that and therefore I don't think there's any point in listing all of the components that make up the system. (That said, I've read elsewhere that Amavisd-new is a bit of a hog, so if you do think this is relevant, let me know and I'll list away.) I'm running a 2 GB linode and am happy to upgrade as necessary. In fact, I will probably upgrade to 3 or 4 GB within the next couple of hours (before the next peak), unless a response to this comes in first suggesting something else.
I've read conflicting opinions about running a mail server on a VPS; in fact, the mail accounts on this linode are ones moved from a dedicated server that I'll be retiring soon. However, I've also read that a "modern" VPS should do just fine.
Any suggestions on possible ways to mitigate the performance issue at peak times, or will doubling the RAM likely solve the issue?
Thanks very much.
Craig
6 Replies
Thanks for your reply. OK, maybe I'll delay the upgrade and watch iotop during the next peak. (Things are quiet right now.) But if I already suspect that I/O is the issue (and assuming I'm right), how will this help me determine whether or not a RAM upgrade will address the issue?
Thanks.
Craig
Use iotop to find the issue - as upgrading isn't going to fix your excessive I/O.
iotop does have a swapin column.
If you want to see what a application is doing use strace -fe trace=file -p {pid}
I'm thinking its something other than memory though with spam handling apps is quite easy to tweek them accidentally into high memory using configurations.
Thanks. You've reminded that I should have included the current graph, which shows what I already knew about swap usage (pretty steady at about 50 MB), so you're probably both right about an upgrade not being likely to help.
The peaks in the graph below are even worse than the averages (of course), so if the averages are almost ten times higher than what Alex is getting, I do have some component that is causing the problem. I suspect it's Amavisd-new. I'll look into it some more.
Appreciate the help.
Craig
![](