From: Jesse Guardiani <[EMAIL PROTECTED]> > Sounds like over-optimizing to me
Never heard of it.
Hehe, well that has a bit of truth to it, but there is a point of diminishing returns.
>, it's works fine now. What problem are > you trying to solve?
Specifically, my qmail-smtpd processes run under a memory limiting program
called 'softlimit'. If the email module loads incoming emails into RAM, then
I have to set up softlimit to limit the size of my qmail-smtpd pipeline's
RAM usage to the normal program usage + the size of the largest email I
want to receive.
That's good, I use that myself, pretty common in most qmail setups.
Typically, my qmail-smtpd process uses 2.2M of RAM, and my python filtering
script, with all modules loaded, uses 4.4M of RAM. So, the smallest I can
set my softlimit is 6.6M, which would normally allow PLENTY (90) SMTP processes
under my designated 600M server RAM limit.
However, now I have to add my max message size to the mix, so if I want a max of 30 SMTP processes running simultaneously, I must set my softlimit to 20M, which gives me 12.4M per message.
I'm not sure I follow your math there unless your max message size just happens to be 5.8M
If the email module didn't gobble the entire email up into RAM, then I wouldn't
have to set my max message size with softlimit, and I could safely run with
a higher maximum qmail-smtpd process count.
True, but then your max message thruput is going to drop through the floor as you messages are now stored on the hard drive which is accessed in milliseconds instead of nanoseconds.
Also, on the TMDA front, if TMDA didn't read the entire email into RAM, then
it would be slightly faster and less likely to eat up my RAM with concurrent
deliveries.
That seems like it would end up being slower to me, though less resourse hungry.
It all makes perfect sense to me. I'm not sure why everyone is so opposed to the idea.
Because buying more ram is cheap, but trying to get a faster hard drive is expensive. Regardless of all that though, it seems like the problem is big messages, not how TMDA handles them. Still, I'm sure if you manage to write something solid that avoids the problems people have mentioned Jason would probably take a good look at it.
Chris Berry [EMAIL PROTECTED] Systems Administrator JM Associates
"Q: How many software engineers does it take to change a lightbulb ? A: It can't be done; it's a hardware problem."
_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
_________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
