natan:
> W dniu 14.01.2022 o 22:18, Wietse Venema pisze:
> > natan:
> > Wietse:
> >> Do you know if the problem is a kernel limit or a per-process limit?
> >> Does master have 4096 open files (including network sockets: ip,
> >> unix-domain, etc.).
> > Wietse:
> >> BTW that last one was a trick question: you need a huge number of
> >> services in master.cf to exceed the 4096 limit. The master needs
> >> three sockets for each service with type 'unix' in master.cf;
> >> services with type 'inet' require two sockets plus one socket per
> >> address in inet_interfaces.
> > natan:
> >> "Do you know if the problem is a kernel limit or a per-process limit?"
> >>
> >> I realy dont known where is it the problem - and how diagnose this
> >>
> >> I long think about kernel limit but ... no have idea
Wietse:
> Were you the person who has a Postfix process limit in the thousands?
> If that is the case, then I suggest that you reduce the Postfix
> process limit to half the number, do "postfix reload", wait for a
> while, and keep reducing the limit to half its value until the
> "resource temporarily unavailable" warnings go away. Also, make
> arrangements for more (and more powerful) servers.
natan:
> I don't know if I am that man with limit thousands
>
> # postconf -nf
...
> default_process_limit = 1200
>
I don't see any settings that turn on content_filter or smtpd_proxy_filter,
but you do have after-filter smtpd processes in master.cf. If your
after-filter smtpd process limits are too low, then your system
would die from congestion.
> # postconf -Mf
...
> smtpd pass - - - - 190 smtpd
> -o receive_override_options=no_address_mappings
...
> smtp-amavis unix - - - - 160 smtp
> -o smtp_data_done_timeout=900s
> -o smtp_send_xforward_command=yes
> -o disable_dns_lookups=yes
>
> #without amavis
> 10.0.100.5:10025 inet n - n - - smtpd
> -o content_filter=
...
> #from external amavis
> xxx.xxx.xxx.199:10027 inet n - n - 400 smtpd
> -o smtpd_proxy_timeout=900s
> -o content_filter=
...
> from log:
> Jan 17 14:05:05 mailserver postfix/master[55510]: warning:
> master_wakeup_timer_event: service qmgr(public/qmgr): Resource
> temporarily unavailable
>
>
> 14:05:01 CET
> ps -e |grep smtpd |wc -l
> 267
>
> 14:06:01 CET
> ps -e |grep smtpd |wc -l
> 266
>
>
> # cat /var/log/mail.log |grep "Jan 17 10:10:54" |grep postscreen |grep
> CONN |wc -l
> 27
> # cat /var/log/mail.log |grep "Jan 17 14:05:04" |grep postscreen |grep
> CONN |wc -l
> 21
> # cat /var/log/mail.log |grep "Jan 17 14:05:05" |grep postscreen |grep
> CONN |wc -l
> 31
> # cat /var/log/mail.log |grep "Jan 17 14:05:06" |grep postscreen |grep
> CONN |wc -l
> 22
>
>
>
> from log:
> Jan 17 10:10:50 thebe4b postfix/postscreen[7103]: warning: cannot
> connect to service private/smtpd: Resource temporarily unavailable
postscreen maintains queues with connetions that still need to be
'tested' (postscreen_pre_queue_limit) and that need to be given to
an smtpd process (postscreen_post_queue_limit).
Each postscreen queue size is $default_process_limit. Both queues
together add up to 2400 network sockets.
If you make this amount the same as your internet-facing smtpd
process limits, then postscreen might leave more resources for the
rest of Postfix.
And then, reduce process limits by half and do "postfix reload",
until the 'Resource temporarily unavailable' message goes away.
> This is a strong machine where load average: 0,95, 1,19, 2,08
Obviously, it doesn't use much CPU power when it can't create a
UNIX-domain socket.
Wietse
