coredns: High memory usage in k8s (was: plugin/cache: change to per RRset)
Currently we cache whole packets (dns.Msg structs), this works, but can be inefficient because
- that’s more data, than we need to a client
- RRsets can be more easily shared between replies.
There are of course some things that are more complex
- the additional data can be cached, but you have to mark it as such (*additional). Not 100% sure what the actual standard in the industry. Not RFC comes to mind
Other than that it might actually be not that hard. DNSSEC must of course be supported. We can re-use the current data structures, except point to RRsets. The assembling of a message is slightly more work. Even the class should just work, if done right of course.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 2
- Comments: 21 (14 by maintainers)
gonna mark this a dup of #2593
@szuecs : Just an information about the use case you brought (and thanks for sharing it!):
The default cache size has been downsized in CoreDNS v1.2.2: instead of 110k entries (in former versions including yours - and you cannot tune lower), you have now, by default, 10k entries. And you can now set its value down to 1024. (Each value is per cache, and there are 2 caches - one for positives replies, one for negative replies).
The effect, I believe is this “plateau” after the burst of 8k/qps : the cache is full, and keeps the memory high (143MBi in your case).
It does not explain the peek at 250MiB, although - If I am right about the cache, and it is full at smaller capacity - the hight of the peek should be lower.