On Fri, Feb 1, 2013 at 11:00 PM, Timo Sirainen <tss@iki.fi> wrote:
On 1.2.2013, at 19.00, Jan-Frode Myklebust <janfrode@tanso.net> wrote:
Have you checked if there's an increase in disk I/O usage, or system cpu usage?
On the directors, cpu usage, and load averages seems to have gone down by about 50% since the upgrade. On the backend mailstores running 2.0.14 I see no effect (but these are quite busy, so less LMTP might just have lead to better response on other services).
Or actually .. It could simply be that in v2.0.15 service lmtp { client_limit } default was changed to 1 (from default_client_limit=1000). This is important with the backend, because writing to message store can be slow, but proxying should be able to handle more than 1 client per process, even with the new temporary file writing. So you could see if it helps to set lmtp { client_limit = 100 } or something.
My backend lmtp services are configured with client_limit = 1, process_limit = 25, and there are 6 backends I.e. max 150 backend LMTP processes if all lmtp is spread evenly between the backends, which it woun't be since backends are weighted differently (2x 50, 2x75 and 2x100).
I assume each director will max proxy process_limit*client_limit to my backends. Will it be OK to have a much higher process_limit*client_limit on the directors than on the backends? It will not be a problem if directors are configured to seemingly handle a lot more simultaneous connections than the backends?
-jf