On Fri, Feb 1, 2013 at 11:00 PM, Timo Sirainen <[email protected]> wrote:
> On 1.2.2013, at 19.00, Jan-Frode Myklebust <[email protected]> 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
