Red Hat Bugzilla – Bug 101660
O_DIRECT seems to chew up (not release) a ton of memory
Last modified: 2007-11-30 17:06:57 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131
Description of problem:
While doing NFS testing with the OraSim test suite, I
notice that all of the memory on the client machine was
being used up (which eventually caused swapping) and not
being released. This happens on NFS mounted filesystem
and locally mount ext3 filesystem.
At first I wasn't alarmed that the all of the system
memory was being used since the machine only had 512MB of
memory and I figured that was just a side effect of running
OraSim. But what did seem strange was once the tests were done
the memory was not being released. The only way to release it
was to unmount the filesystem.
total: used: free: shared: buffers: cached:
Start : Mem: 524255232 304726016 219529216 0 116555776 44355584
End : Mem: 524255232 510078976 14176256 0 23855104 437854208
Umount: Mem: 524255232 64393216 459862016 0 7434240 6696960
Start : Swap: 1073700864 8192 1073692672
End : Swap: 1073700864 12288 1073688576
Umount: Swap: 1073700864 12288 1073688576
Now maybe this is normal, and the memory will eventually be
release and re-used as needed... but I just sees strange that
one process doing O_DIRECT writes could chew up all the
system memory and then not release it...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Created attachment 93399 [details]
Meminfo before the start of the testing
Created attachment 93400 [details]
Meminfo after the testing
Created attachment 93401 [details]
meminfo after the umount
There are lots of possibilities here. A leak is very very unlikely, because
those tend not to get cleaned up at unmount.
So one possibility is that you're not actually doing raw IO. When OraSim
creates a file, the file is initially sparse (ie. no disk blocks are actually
allocated, the blocks get filled in on demand.) As it writes to the file, we're
filling in those holes, but O_DIRECT is disabled for such writes because of
possible races: the kernel falls back to buffered writes and O_SYNC.
Are you letting OraSim create the files itself, or are you preallocating the
files with "dd < /dev/zero" beforehand?
I was leting OraSim create the files
Then that's expected behaviour. If performance is crashing as a result, then
that's a VM problem which you should probably raise with Rik, as plain buffered
IO shouldn't bring the system to its knees!
Please try reproducing with pre-created files and reopen this bug if the