I am trying to understand the behavior of the dirty_expire_centisecs parameter on servers with kernels 2.6 and 3.0.
Kernel documentation says (vm.txt / dirty_expire_centisecs) "Data that has been contaminated in memory longer than this interval will be written out the next time the fluorescent stream wakes up."
which means that dirty data that was in memory less than this interval will not be recorded.
According to my testing, the behavior of dirty_expire_centisecs is as follows: when the writeback timer fires before the expiration timer expires, then no page will be cleared, otherwise all pages will be cleared. If the background_bytes limit is reached, it clears all or part depending on the speed, regardless of both timers.
My testing tells me about a low write level (less than 1 MB per second), the dirty_background_bytes trigger will hide all dirty pages and at slightly higher data transfer rates (above 2 MB per second), it clears only part of the dirty data, regardless of the expiry value .
This is different from what vm.txt says. It makes sense not to clear the latest data. For me, the observed behavior is not logical and almost useless. What do you guys think?
My test setup: A server with 16 GB of RAM with Suse 11 SP1, SP2 and RedHat 6.2 (setting up multiple downloads)
vm.dirty_bytes = 50000000 // 50MB <br> vm.dirty_background_bytes = 30000000 // 30MB <br> vm.dirty_writeback_centisecs = 1000 // 10 seconds <br> vm.dirty_expire_centisecs = 1500 // 15 seconds <br>
with a tool to write files where I can control the speed of writing and writing () per second.
source share