From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux) KHTML/3.4.2 (like Gecko) Description of problem: OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 328224 328222 99% 0.02K 2104 156 8416K fasync_cache ... and growing slowly. it is my understanding that fasync_cache should not be larger than the number of open files in the system (currently ~6000) the system is a dual opteron (single core) serving nfs, samba, http, and shells. a post[1] to lkml leads me to believe it is samba related. Haven't tested it yet. [1] http://www.ussg.iu.edu/hypermail/linux/kernel/0510.2/1589.html, http://www.ussg.iu.edu/hypermail/linux/kernel/0510.3/0034.html Version-Release number of selected component (if applicable): kernel-smp-2.6.13-1.1532_FC4 How reproducible: Didn't try Steps to Reproduce: 1. serve smb using samba (?) 2. slabtop Actual Results: slabtop shows a large fasync_cache Expected Results: small fasync_cache Additional info: running lvm atop raid-1
I can confirm it is samba related. mounting a share on another machine (mount -t cifs) and doing a subversion checkout on that mount causes the cache to grow by several hundred objects per second. setting the fs.leases-enables sysctl to 0 stops the leak.
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
2.6.14-1.1637_FC4smp is bad.
fix: http://kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=dc15ae14e97ee9d5ed740cbb0b94996076d8b37e bonus points: http://kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f3a9388e4ebea57583272007311fffa26ebbb305
fixed in cvs, will be in builds 1640 and above. Will get this pushed out in a day or so. (Interim builds will appear at http://people.redhat.com/davej/kernels/Fedora/FC4/)
excellent! thank you.