Speed up queue injection
in [Postfix]
|
From: "J. Roeleveld" on 13 Aug 2010 09:22 On Friday 13 August 2010 14:23:51 Wietse Venema wrote: > Ralf Hildebrandt: > > * Ram <ram(a)netcore.co.in>: > > > Mail in plain text format , mime encoded message > > > > OK! > > > > > Currenlty I get 40/s - 45/s > > > > That sounds normal. Any filtering (in these cases you should inject in > > a way that bypasses and filters) > > > > > But I want it to be atleast 100/s > > > > Two machineS? > > relay boxes > > > > > Delivery is not at all an issue , because postfix gives it to further > > > relay boxes which are under our control again. > > > > Why not inject to the further relay boxes? > > > > > Do I need to increase the hardware > > > > It could be :) > > Other options: increase input concurrency, or play with in_flow_delay. > Note that increasing your input rates will cause output rates to drop. > It's all about competing for disk access. > > Wietse Further options, I think: - Disable filtering (provided the only possible connections are related to these emails - put the queue on a ram-disk (8GB Ram, might leave 6GB for the queue, would this be sufficient?) These are theoretical, I have no idea if this is at all possible and if this can cause further issues elsewhere? -- Joost
From: Noel Jones on 13 Aug 2010 13:58
On 8/13/2010 8:22 AM, J. Roeleveld wrote: > On Friday 13 August 2010 14:23:51 Wietse Venema wrote: >> Ralf Hildebrandt: >>> * Ram<ram(a)netcore.co.in>: >>>> Mail in plain text format , mime encoded message >>> >>> OK! >>> >>>> Currenlty I get 40/s - 45/s >>> >>> That sounds normal. Any filtering (in these cases you should inject in >>> a way that bypasses and filters) >>> >>>> But I want it to be atleast 100/s >>> >>> Two machineS? >>> relay boxes >>> >>>> Delivery is not at all an issue , because postfix gives it to further >>>> relay boxes which are under our control again. >>> >>> Why not inject to the further relay boxes? >>> >>>> Do I need to increase the hardware >>> >>> It could be :) >> >> Other options: increase input concurrency, or play with in_flow_delay. >> Note that increasing your input rates will cause output rates to drop. >> It's all about competing for disk access. >> >> Wietse > > Further options, I think: > - Disable filtering (provided the only possible connections are related to > these emails Presumably the client would be in mynetworks, which should bypass most or all restrictions, so this is unlikely to make much difference. Unless you're doing something silly like 1000 body_check rules or using a content_filter or milter. > - put the queue on a ram-disk (8GB Ram, might leave 6GB for the queue, would > this be sufficient?) Putting the queue on ramdisk is only for spammers who don't particularly care if their mail is lost. But putting the queue on an enterprise-quality SSD would almost certainly help. -- Noel Jones |