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 ? --