Add the memory envelope, pprof, and a per-packet fix on the UDP path
A cgroup OOM kill is the worst outcome available to a resolver: an outage rather than a cache miss, with no chance to serve stale on the way out. So: - memory.limit / memory.reserve / memory.cache_max_bytes, a new config section. limit becomes a GOMEMLIMIT through debug.SetMemoryLimit, reduced by the reserve. The reserve exists because the Go heap does not account for goroutine stacks, runtime metadata, or the bbolt mmap backing the cache snapshot and the query log — handing the runtime the full cgroup limit is how you get killed by a mechanism that believed it had headroom. - config.Size, so a budget reads as "512MiB" rather than a byte count converted by hand. Strict about junk: "512MiBx" is an error. - The cache byte budget is now actually fed to the LRU. It already enforced maxBytes per shard on insert, but had no setter and nothing ever called one, so the footprint of cache.size was unbounded: one cached ANY or TXT answer can be tens of kilobytes, so 500k entries is anywhere from 150MB to several GB depending on what the traffic asked for. - api.pprof mounts net/http/pprof on the admin listener. The pprof handlers sit on the app-level mux, not inside the API's own handler, so they would bypass the auth middleware entirely; the option is therefore refused unless every admin address is loopback. Profiling means port-forwarding, so this is safe by construction rather than by policy, and cmdline cannot leak an argument that happens to be a key. - serveUDP was calling net.ResolveUDPAddr per packet. The peer already is a *net.UDPAddr; that call builds a string, re-parses the port and allocates on the busiest path in the process. Also fixes a flaky test: TestParallelPolicyAnswersFromTheFastestUpstream asserted the slow upstreams were hit, but the fan-out cancels on the first answer, so whether they were dispatched before cancellation is a real race. It now asserts the answer came from the fast upstream and that nothing waited.
This commit is contained in:
1 parent
1bdb0b081c
commit
b0e6b3bb92
11 files changed
+382
-6
No files matched your search
Vendored
+21
-1
@@ -26,6 +26,11 @@ type LRU struct {
|
||||
// reload resizes the cache from the API goroutine while queries are
|
||||
// inserting in every shard.
|
||||
perShard atomic.Int64
|
||||
// maxBytes bounds the whole LRU by accounted bytes, divided between the
|
||||
// shards the same way perShard is. 0 means unbounded. This is the budget
|
||||
// that actually protects the process: perShard alone cannot, because an
|
||||
// entry's size is set by the answer, not by the count.
|
||||
maxBytes atomic.Int64
|
||||
|
||||
// counters are the hot-path stats, kept as atomics so Get does not need
|
||||
// the lock just to record a hit.
|
||||
@@ -60,6 +65,20 @@ type lruItem struct {
|
||||
|
||||
// NewLRU builds an LRU holding at most size entries across shards shards
|
||||
// (rounded up to a power of two, minimum 1).
|
||||
// SetMaxBytes bounds the LRU by accounted bytes, dividing the budget between
|
||||
// shards the same way the entry budget is. Zero removes the bound. Existing
|
||||
// entries are kept; a reload that tightens the budget reclaims on the next
|
||||
// insert, exactly like the entry budget.
|
||||
func (l *LRU) SetMaxBytes(n int64) {
|
||||
if n < 0 {
|
||||
n = 0
|
||||
}
|
||||
l.maxBytes.Store(n)
|
||||
}
|
||||
|
||||
// MaxBytes reports the whole-LRU byte budget, or 0 when unbounded.
|
||||
func (l *LRU) MaxBytes() int64 { return l.maxBytes.Load() }
|
||||
|
||||
func NewLRU(size, shards int) *LRU {
|
||||
if shards <= 0 {
|
||||
shards = DefaultShardCount
|
||||
@@ -171,7 +190,8 @@ func (l *LRU) Put(k Key, e *Entry) {
|
||||
l.bytes.Add(int64(e.Bytes))
|
||||
var dropped int
|
||||
budget := int(l.perShard.Load())
|
||||
for s.ll.Len() > budget {
|
||||
byteBudget := l.maxBytes.Load() / int64(len(l.shards))
|
||||
for s.ll.Len() > budget || (byteBudget > 0 && s.bytes > int(byteBudget)) {
|
||||
oldest := s.ll.Back()
|
||||
if oldest == nil {
|
||||
break
|
||||
|
||||
Reference in new issue
Block a user