diff options
| author | sl <sl@stanleylieber.com> | 2021-02-19 21:29:55 -0500 |
|---|---|---|
| committer | sl <sl@stanleylieber.com> | 2021-02-19 21:29:55 -0500 |
| commit | 4bbb3b0b21edd81be37a0a6ad12c76a63d127bed (patch) | |
| tree | f57ff08220429c84e201e201df8106a44aaf3ec2 | |
| parent | 29e8ea26f2f9af2b9924e16dffd784bc5ae5685e (diff) | |
| download | plan9front-4bbb3b0b21edd81be37a0a6ad12c76a63d127bed.tar.xz | |
/sys/src/cmd/ndb/dns.h:
---
To: 9front@9front.org
Date: Sun, 07 Feb 2021 14:56:39 +0100
From: kvik@a-b.xyz
Subject: Re: [9front] transient dns errors cause smtp failure
Reply-To: 9front@9front.org
I think I found a reason for DNS failing on known good domains.
/sys/src/cmd/ndb/dns.h:156,157
/* tune; was 60*1000; keep it short */
Maxreqtm= 8*1000, /* max. ms to process a request */
So, 8 seconds is how much the resolver will bother with a request it
has been handed, before dropping it on the floor with little
explanation.
It seems quite possible that this is too short a timeout on a machine
during a spam queue run, which predictably stresses the compute and
network resources.
In turn, negative response caching might explain why a particular
unlucky domain would basically stop receiveing any mail for a while.
I'm dying to know if bumping this limit would clear up the queue of
such DNS errors.
---
[narrator: it did.]
| -rw-r--r-- | sys/src/cmd/ndb/dns.h | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/sys/src/cmd/ndb/dns.h b/sys/src/cmd/ndb/dns.h index 100bd1b3b..c3d3efcbc 100644 --- a/sys/src/cmd/ndb/dns.h +++ b/sys/src/cmd/ndb/dns.h @@ -151,8 +151,8 @@ enum /* parallelism: tune; was 32; allow lots */ Maxactive= 250, - /* tune; was 60*1000; keep it short */ - Maxreqtm= 8*1000, /* max. ms to process a request */ + /* tune; was 8*1000; that was too short */ + Maxreqtm= 60*1000, /* max. ms to process a request */ Notauthoritative = 0, Authoritative, |