On 11/20/2012 6:06 AM, Wietse Venema wrote: > Alex: >> Nov 19 20:39:03 mail01 postfix/smtpd[19820]: lost connection after >> CONNECT from listserver.translateplanmulti.info[198.41.120.7] > > Your server is too slow, so that connections pile up in front of > it.
translateplanmulti.info is a snowshoe domain, 198.41.120.0/24, and everyone should be blocking it. Postscreen by default stops bots, not snowshoe ratware. Alex' smtpds and amavis/SA may be getting hammered by snowshow connections, though this one log entry alone doesn't prove such. > Find out where the bottle neck is by SYSTEMATICALLY MEASURING latency > (not: manual "telnet to port 25" tests): name lookups, header checks, > body checks, file system, CPU, memory, and so on. If you can't > figure it out then hire a professional. Before expending the effort on full bottleneck analysis, I'd recommend Alex should first concentrate on blocking more spam outright before it reaches his smtpds and thus his content filters. My logs back to the 18th show the same snowshoe spammer, with BRBL blocking every connection: Nov 18 16:57:41 greer postfix/smtpd[9352]: NOQUEUE: reject: RCPT from listserver.translateplanmulti.info[198.41.120.7]: 554 5.7.1 Service unavailable; Client host [198.41.120.7] blocked using b.barracudacentral.org .... Nov 20 15:50:17 greer postfix/smtpd[19255]: NOQUEUE: reject: RCPT from openview.translateplanmulti.info[198.41.120.9]: 554 5.7.1 Service unavailable; Client host [198.41.120.9] blocked using b.barracudacentral.org Alex has BRBL in his postscreen config, but apparently his scoring setup is not triggering a rejection. Fixing that will stop this particular snowshoe spammer, and many others, from reaching his smtpds and content filters. Reducing that load will likely help this delay issue. This can also be done with a local block list such as a CIDR table for subnets, or an indexed table for domains, though this involves much more labor than getting DNSBLs to do the work for you. In addition, the Linux kernel SYN flood warning indicates Alex needs a firewall in front of this host, or a better configuration on it, or that he should implement packet filtering, or better packet filtering, on the host itself, via iptables rules. If due to policy most spam needs to go through the content filters for flagging, a 4x1TB 7.2K RAID5 setup may be insufficient to sync the load due to parity RAID's horrible random write throughput. A four disk RAID10 will typically yield 3x or more write throughput for a mail workload. This of course depends on your RAID controller, its cache size and configuration, etc. If you're using md/RAID5 your random IO will be pretty bad. You may want to analyze IO throughput and latency on your queue filesystem/device. If you're using EXTx for the queue filesystem, switching to XFS will yield a decent increase in queue throughput as well. -- Stan
