> I'm having strange behavior in dovecot 2.3.16. > It's opening dozens of dovecot/config process and consuming all server > memory. Normally each process consumes between 700Mb and 1Gb of ram. > > Would anyone have an idea about this? > > service config { > vsz_limit = 2048M > idle_kill = 60s > service_count = 1024 > }Not sure it's related, but if you have service_count not 0 or 1, there is a strange interaction with other limits that could cause processes to hang around. My description of problem https://www.mail-archive.com/dovecot%40dovecot.org/msg85850.html Your situation is slgihtly different (service not imap_login, and idle_kill timeout should reduce lingering processes that caused my problem), but try setting service_limit to either 0 or 1 and see if your problem goes away, or gets worse. You can also see how many file descriptors are being held by the config process, and see the behaviour over time (e.g. monitor /proc/{pid}/fd/*); maybe that will give you a clue as to what the config process is doing. Joseph Tam <jtam.home at gmail.com>
> On 16/08/2022 03:40 EEST Joseph Tam <jtam.home at gmail.com> wrote: > > > > I'm having strange behavior in dovecot 2.3.16. > > It's opening dozens of dovecot/config process and consuming all server > > memory. Normally each process consumes between 700Mb and 1Gb of ram. > > > > Would anyone have an idea about this? > > > > service config { > > vsz_limit = 2048M > > idle_kill = 60s > > service_count = 1024 > > } > > Not sure it's related, but if you have service_count not 0 or 1, there > is a strange interaction > with other limits that could cause processes to hang around. My > description of problem > > https://www.mail-archive.com/dovecot%40dovecot.org/msg85850.html > > Your situation is slgihtly different (service not imap_login, and > idle_kill timeout should reduce > lingering processes that caused my problem), but try setting > service_limit to either 0 or > 1 and see if your problem goes away, or gets worse. > > You can also see how many file descriptors are being held by the > config process, and > see the behaviour over time (e.g. monitor /proc/{pid}/fd/*); maybe > that will give you a clue > as to what the config process is doing. > > Joseph Tam <jtam.home at gmail.com>The *default* configuration for service config is usually just fine. Is there some reason you decided to modify it in first place? Aki