Hi, folks,
thanks for your answers so far
Just a few more input:
There is no rate limiting, tar pitting or so .
I created a special "accept" ACL just at the beginning of my acl_smtp_rcpt
I created a special router at the beginning of my routers.
I commented out most of my redirect routers.
So most of the ACL and routing stuff in my config is skipped.
In the strace log I see the handling of the remaining stuff of my exim config.
But this handling is done after the observed delay between the RCPT line and the socket line
RAM is fine, one of my four cores is at 100% during my tests, it's a Debian 10 buster OS
with an exim 4.94 from the Debian 11-backport
I will try your proposals and keep you informed.
Regards, Olaf
On 3/11/21 9:59 PM, Olaf Hopp (SCC) via Exim-users wrote:
> Dear collegues,
>
> my administration writes one(!) email with more than 3000 receipients
> in the envelope. (Please, no discussion about the sense of this. Period.)
>
> Receiving that mail takes about 2 two hours.
> Delivering that mail is done very quick, as usual.
>
> I started debugging this and I recognized that
> after every "RCPT TO" it took a sucessive increasing time
> until the "250 Accepted" was answered.
> At the beginning this was a 10th of a second.
> After 1000 recipients there was a delay of ~one second
> after the 2000th recipients this delay increased smoothly
> to 2 secends ofter each rcpt-to
>
> I threw away all my bells and whistles in the exim config,
> but no success.
>
> So I started "strace" to see whats happening:
>
> At the beginning I see
> 18:35:36.048265 read(7, "RCPT TO:<AAAA@BBBBB>\r\n", 8191) = 45
> 18:35:36.063187 alarm(0) = 300
> 18:35:36.063233 rt_sigaction(SIGALRM, {sa_handler=0x55bc6f392180, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f8eff4d9730}, NULL, 8) = 0
> 18:35:36.140936 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 9
> see the nearly zero difference between the RCPT line and the socket line
>
> After ~1000 recipients I have:
> 18:40:51.670874 read(7, "RCPT TO:<XXXXX@YYYYYY>\r\n", 8191) = 43
> 18:40:51.685450 alarm(0) = 300
> 18:40:51.685538 rt_sigaction(SIGALRM, {sa_handler=0x55bc6f392180, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f8eff4d9730}, NULL, 8) = 0
> 18:40:52.277971 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 9
> so half a second between the rcpt line and the socket line
>
> After ~2000 recipients:
> 19:06:28.229652 read(7, "RCPT TO:<ZZZZ@ZZZZ>\r\n", 8191) = 29
> 19:06:28.244041 alarm(0) = 300
> 19:06:28.244253 rt_sigaction(SIGALRM, {sa_handler=0x55bc6f392180, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f8eff4d9730}, NULL, 8) = 0
> 19:06:29.776217 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 9
> about 1.5 seconds between rcpt and the socket line
>
> There are no dropped lines between the RCPT line until the socket line in the strace output
>
> Any ideas what's happening here ?
>
> (testing was done with "swaks" talking directly to the exim)
>
> Regards, Olaf
>
>
>
>
--
Karlsruher Institut für Technologie (KIT)
Steinbuch Centre for Computing (SCC)
Dipl.-Geophys. Olaf Hopp
Zirkel 2
Gebäude 20.21, Raum 316
76131 Karlsruhe
Telefon: +49 721 608-48009
E-Mail: Olaf.Hopp@???
Web:
www.scc.kit.edu
Sitz der Körperschaft:
Kaiserstraße 12, 76131 Karlsruhe
KIT - Die Forschungsuniversität in der Helmholtz-Gemeinschaft
