W dniu 21.12.2021 o 18:15, Wietse Venema pisze:
> natan:
>>> postscreen tries to hand off each 'good' connection to an smtpd
>>> process. Apparently, there are not enough of smtpd processes to
>>> take those connections, and some kernel-internal queue is filling up 
>>> resulting in an EAGAIN kernel error code.
>>>
>>> Possible causes:
>>>
>>> 1) The default_process_limit of 1200 is too low. In that case a
>>> higher default_process_limit would help.
>> Hm I try up 20%
> Please don't waste time with minuscule changes. I suggest doubling
> the number to see if it makes a difference (don't forget "postfix
> reload").
I change x2
And today I get other error:
Dec 22 10:38:28 mx4 postfix/proxymap[27207]: warning: connect to mysql
server 10.x.x.10:3307: Lost connection to MySQL server at 'reading
authorization packet', system error: 11 "Resource temporarily unavailable"
Dec 22 10:38:28 m4 postfix/cleanup[26889]: warning:
proxy:mysql:/etc/postfix/mysql/mysql_recipient_bcc_maps_user.cf lookup
error for "....@zzzzzz.com"

10.x.x.10 - is gallera klaster wirth 3 nodes (and max_con set to 1500
for any nodes)

when I get this eror I check number of connections

smtpd : 125

smtp      inet  n       -       -       -       1       postscreen
smtpd     pass  -       -       -       -       -       smtpd -o
receive_override_options=no_address_mappings

and total: amavis+lmtp-dovecot+smtpd-o
receive_override_options=no_address_mappings : 335
from: ps -e|grep smtpd |wc -l


>> but:
>> for local lmt port:10025 - 5 connection
>> for incomming from amavis port: 10027- 132 connections
>> smtpd - 60 connections (
>> ps -e|grep smtpd - 196 connections
> 1) You show two smtpd process counts. What we need are the
> internet-related smtpd processes counts.
>
> 2) Network traffic is not constant. What we need are process counts
> at the time that postscreen logs the warnings.
>
>>> 2) Your kernel cannot support the default_process_limit of 1200.
>>> In that case a higher default_process_limit would not help. Instead,
>>> kernel configuration or more memory (or both) would help.
>> 5486 ?        Ss     6:05 /usr/lib/postfix/sbin/master
>> cat /proc/5486/limits
> Those are PER-PROCESS resource limits. I just verified that postscreen
> does not run into the "Max open files" limit of 4096 as it tries
> to hand off a connection, because that would result in an EMFILE
> (Too many open files) kernel error code.
>
> Additionally there are SYSTEM-WIDE limits for how much the KERNEL
> can handle. These are worth looking at when you're trying to handle
> big traffic on a small (virtual) machine. 
>
>       Wietse
How I check ?

--

Reply via email to