--On 23 February 2009 16:47:20 +1100 Ted Cooper <[email protected]> wrote:
> Marc Perkel wrote: >> Well, I'm not up to 4096 yet but often run 900 on Monday mornings. I'm >> filtering spam for over 4000 domains and this is the main box. I might >> have a project coming up processing far more volume that now. >> >> This box is fast. I'm offloading spamassassin on several other servers. >> I'm using a ram disk for the email queue. I might be adding another >> 12,000 domains. I'm not doing a lot of delays, although I do throw in a >> few seconds of suspicious connections but no more than 10 seconds total. >> So although 4096 sounds like a lot if you throw enough email volume on >> it you can get there. > > The 4096 limit might be more aimed at the limits imposed by linux > itself. There are open file descriptor limits (default limits are 1024 > per process) which you may reach. I suspect there would be some others > too, but they are all trivial to increase. It's just a matter of > adjusting them all which is why this would be considered a local tuning > customisation and not something that would enter the distribution code > base. > > I know you already use multiple MX records, have you considered > splitting the MX onto different machines so that you have a fail over? > Or use round robin DNS to split the traffic between multiple machines? All that might be doable, but it's a shame to have to deploy more hardware because of an arbitrary limit on process numbers. In fact, it'd be downright inefficient (and irresponsible what with global warming, and all). Marc (or others) may well be using clusters for resilience, but when failover directs all the traffic to one member, that member needs to be able to satisfy all the demand. I sympathise with Marc, because I'm using OSX, which has a hard coded kernel limit of 2500 processes per machine. It's a problem for me because of our IMAP process counts, and it really is a headache having to deploy more machines when I've got plenty of overhead with respect to RAM, disk I/O, network I/O and so on. So, Exim's limit isn't reached on my machines, but nevertheless the limit needs revisiting for those who don't have my problem. Marc's right. The limit is too low for modern hardware. -- Ian Eiloart IT Services, University of Sussex x3148 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
