[Bugme-janitors] [Bug 9182] Critical memory leak (dirty pages)

bugme-daemon at bugzilla.kernel.org bugme-daemon at bugzilla.kernel.org
Mon Dec 17 05:28:48 PST 2007


http://bugzilla.kernel.org/show_bug.cgi?id=9182





------- Comment #43 from anonymous at kernel-bugs.osdl.org  2007-12-17 05:28 -------
Reply-To: osterried at jesse.de

Hello,

> >   - ext3 on RAID1 (MD): / - rootflags=data=journal
> 
> It wouldn't surprise me if this is specific to data=journal: that
> journalling mode is pretty complex wrt dairty-data handling and isn't well
> tested.
> 
> Does switching that to data=writeback change things?
> 
> THomas, do you have ext3 data=journal on any filesytems?

On all systems i have ext3 journal_data enabled as a default mount option.

The test with "sync; sleep 1; sync; cat /proc/meminfo | grep -i dirty" is quite
interesting:
on those machines with kernel 2.6.20 the amount of dirty pages remains high:

# cat /proc/vmstat /proc/meminfo |grep -i dirt
nr_dirty 101873
Dirty:          407492 kB
# sync
# sync
# cat /proc/vmstat /proc/meminfo |grep -i dirt
nr_dirty 99266
Dirty:          397064 kB

whereas with kernel 2.6.18-5, the amount of dirty pages really goes to zero:
# cat /proc/meminfo /proc/vmstat |grep -i dirt
Dirty:             232 kB
nr_dirty 58
# sync
# sync
# cat /proc/meminfo /proc/vmstat |grep -i dirt
Dirty:               0 kB
nr_dirty 0

The level of which amount of dirty pages the system goes into trouble varies.
The 2GB RAM machine has problems with start of 400MB dirty pages.
Another machine with less RAM has problems with less MB dirty pages.
/proc/sys/vm/dirty_ratio is at the default value: 40.

The amount of dirty-pages on kernel 2.6.20 and up only decreases a bit when
doing sync, but still remains at the high value, and increases day by day.

We have only ext3fs. No NFS. 

The machines which do a daily rsync backup to a separate disk go into troubles
after some time (one machine after 10 days, others after more time). Some
which have no rsync backup gomore seldomly  into trouble, perhaps because
without
daily rsync, the amount of dirty pages increases more slowly. This is why i
see rsync as a catalysator for the problem (but not the cause). Without rsync,
we have had also machines hiting that kind of bug.


Btw, while monitoring /proc/meminfo with the command
  "while true; do date;  cat /proc/meminfo |grep -i Dirt ; sleep 10; done | tee
/var/log/kernel_vm_protokoll.txt",
i found this kind of out-of-order writing:
Sa Aug  4 00:01:38 CEST 2007
Dirty:            1664 kB
Sa Aug  4 00:01:48 CEST 2007
Dirty:            1812 kB
Sa Aug  4 00:01:58 CEST 2007
Dirty:            1948 kB
Sa Aug  4 00:02:08 CEST 2007
Sa Aug  4 00:02:08 CEST 2007
Dirty:            2976 kB
Dirty:            2976 kB
Sa Aug  4 00:02:08 CEST 2007
Sa Aug  4 00:02:08 CEST 2007
Dirty:            2976 kB
Dirty:            2976 kB
Sa Aug  4 00:02:18 CEST 2007
Dirty:            2092 kB
Sa Aug  4 00:02:28 CEST 2007
Dirty:            2136 kB


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


More information about the Bugme-janitors mailing list