W dniu 22.12.2021 o 11:25, natan pisze: > 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 lookuperror > for "....@zzzzzz.com" and other Dec 22 10:38:11 m4 postfix/proxymap[27124]: warning: connect to mysql server 10.x.x.10:3307: Lost connection to MySQL server at 'reading authorization packet', system error: 0 "Internal error/check (Not system error)"
> > 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 ? > > -- > --
