4 ms·
I tried to debug a very similar-sounding issue a couple of years back. Many GB used in dentrys, not shrinking when asked, no obvious cause. Sadly I have no ker
by bboreham 5y ago
I tried to debug a very similar-sounding issue a couple of years back. Many GB used in dentrys, not shrinking when asked, no obvious cause.
Sadly I have no kernel hacking skills, don’t even know what a dentry is. Kudos to the author.
- a1369209993 5y agoFWIW, I'd assume that's "directory entry", the (file name,inode number) pair that's used to associate names of files in a directory with the data structures (inodes) describing those files. Not sure how you'd end with many gigabytes of them though, they're usually on the order of length-of-name + 8-24 bytes IIRC, so that would be around tens of millions of files?
- bboreham 5y agoFrom TFA: “it seems that dentry caches consume around 2GB memory under one memory cgroup”. My issue happened after stress-testing Kubernetes by repeatedly starting and stopping many containers. So over time there could be tens of millions of files bind-mounted.
- bboreham 5y agoHere is the output from 'slabtop' that I captured at the time, right after a commanded cache drop - looks like dentry wasn't the biggest component, but there were 32 million of them: OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 534740452 533096794 99% 0.03K 4312423 124 17249692K kmalloc-32 32734926 23946797 73% 0.19K 1558806 21 6235224K dentry 86560 86558 99% 64.00K 86560 1 5539840K kmalloc-65536 2124646 1994340 93% 2.00K 1062323 2 4249292K kmalloc-2048 1013664 1013606 99% 4.00K 1013664 1 4054656K kmalloc-4096 14592544 11935392 81% 0.12K 456017 32 1824068K kmalloc-128 1300528 1158942 89% 1.00K 325132 4 1300528K kmalloc-1024