Re: [exim] Mail with thousands recipients takes exponential …

Página Inicial
Delete this message
Reply to this message
Autor: Jeremy Harris
Data:  
Para: exim-users
Assunto: Re: [exim] Mail with thousands recipients takes exponential longer time
On 11/03/2021 20:59, Olaf Hopp (SCC) via Exim-users wrote:
> 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


> 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


In a test here I'm seeing under a mmillisecond between RCPT commands
processed by the server, even after 2000 of them:

21:51:59.681 12433 end of inline ACL: ACCEPT
21:51:59.681 12433 SMTP>> 250 Accepted
21:51:59.681 12433 SMTP<< rcpt to:<x@y>
21:51:59.681 12433 processing "accept" (/home/jgh/git/exim/test/test-config 29)
21:51:59.681 12433 accept: condition test succeeded in inline ACL
21:51:59.681 12433 end of inline ACL: ACCEPT
21:51:59.681 12433 SMTP>> 250 Accepted
21:51:59.681 12433 SMTP<< data
21:51:59.681 12433 SMTP>> 354 Enter message, ending with "." on a line by itself
21:51:59.681 12433 search_tidyup called
21:51:59.681 12433 DMARC: no dmarc_tld_file
21:51:59.681 12433 >>Headers received:
21:51:59.682 12433

This was running the server with -d+all and with a log_selector = +millisec.
Are you able to do that for a test?

The other useful item you might be able to infer from your strace is: what
was that socket used for?

--
Cheers,
Jeremy