RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 819922 - Dentry and innodes shows an alarming increase
Summary: Dentry and innodes shows an alarming increase
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.2
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: rc
: ---
Assignee: Red Hat Kernel Manager
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-08 15:57 UTC by coder43v3r
Modified: 2012-05-09 18:31 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-09 18:31:41 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description coder43v3r 2012-05-08 15:57:15 UTC 
Description of problem:

I am running a CentOS 6.2 64 bit on top of VMWare ESXi 5, the dedicated server is a Dell dual Xeon with 32 giga of memory.
When the server is idle, load is 0, the dentry and innodes rises and rises and gets to a point of slowing down the server and OOM kicks in.
slabtop shows that dentry is rising and that the kernel never frees this memory for other applications.
When i do a free -m and look at the -/+ buffers/caches line, the line that tells how much applications are using real memory, the entry is rising and reflects the dentry leak.
When i try to do a:  sync & echo 2 > /proc/sys/vm/drop_caches  the echo gets stuck in an endless loop in the kernel, as a zombie, taking 100% cpu, and i can not kill it in any way, the only thing left to do is a restart.

Version-Release number of selected component (if applicable):
kernel version: 2.6.32-220.13.1.el6.x86_64
CentOS version: 6.2

How reproducible:
Install CentOS 6.2 on top of VMWare ESXi 5

Steps to Reproduce:
1. Just install
2.
3.
  
Actual results:
running free -m and examining the -/+ caches/buffers line shows a steady increase.
running slabtop shows a steady and alarming increase in dentry size.

Expected results:
There should be no reason for dentry cache to increase so alarmingly on an idle server, i know all the claims about Linux is taking as much RAM... and it will give it back... but that is not the case ! this leads to slow server and OOM.

Additional info:
I know that i am not using REHL, but CentOS kernel is using REHL kernel and they are the same.
Comment 2 Ric Wheeler 2012-05-09 18:31:41 UTC 
Red Hat bugzilla is a support tool for customers - you should take the issue to the upstream kernel lists or community when you are self supporting.

For community support, it is best to reproduce on a recent upstream kernel (i.e., not on CentOS).

Good luck!
Note You need to log in before you can comment on or make changes to this bug.