Hello Ben, i'm a collegue of Daniele and I'd like to add some more information on this issue, which we're still facing with 3.2.35-2~bpo60+1 .
First of all, we saw there's a new version for bpo, do you want us to update and see if it fixes? We don't want to keep changing the platform (if not under your request) as it might introduce a variability that won't allow to pin-point the problem. About the bind-mounts : yes, we're a heavy clients of bind-mounts :) And while it's true they increase over time, we have a huge spike of mounts in the first period of operation of the node (after reboot, restarting the web service won't umount them), and when it reaches the "balance" the number of mounts increases very slowly over time. We have >300K bind-mounts and 1K per mount it means >300Mb of memory usage, but we've seen even 10GB of slab usage. Now, for example, on a machine up since 8 days I see: OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 7269540 7269516 99% 0.19K 363477 20 1453908K size-192 2564196 2324737 90% 0.98K 641049 4 2564196K nfs_inode_cache while I can see why we have the nfs_inode_cache high in the slabtop (we use intensively NFS mounts), we still observe the size-192 using quite a bit of memory , more than expected with the 1K-per-mount rules. Please let us know if you need more information, if we can run some diagnostics or try some solutions, it's really important for us to get that fixed. cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAB4XWXyRnSrs9PE5=Z=xsc7tzig-2md0i7y9c1foxvwn_sy...@mail.gmail.com
