I am doing some performance testing of XFS. I am using Ubuntu 11.10 amd64 (server), on an i3-2130 (3.4GHz) with 8GB RAM. This will eventually run with a bunch of Hitachi 3TB Deskstar drives, but the
Write order is different to read order, and read performance is sensitive to cache hit rates and IO latency. When you working set is larger than memory (which is definitely true here), read performan
Absolutely. It's reading the entire files - I had grepped out the read(...) = 8192 lines so that the stat/open/read/close pattern could be seen. Yes it does. The particular application I'm tuning for
Updates: (1) The bug in bonnie++ is to do with memory allocation, and you can work around it by putting '-n' before '-s' on the command line and using the same custom chunk size before both (or by us
You don't just read a single file at a time but multiple ones, don't you? Try playing with the following tweaks to get larger I/O to the disk: a) make sure you use the noop or deadline elevators b) i
You forgot the directory IO. If you've got enough entries in the directory to push it out to leaf/node format, then it could certainly take 3-4 IOs just to find the directory entry you are looking fo
Right, because it is doing buffered IO and reading and writing into the page cache for small Io sizes is much faster than waiting for physical IO. Hence there is much less of a penalty for small buff
Ah. And if the IOs are not stacked up, then the platter has to rotate nearly a whole turn to perform the next one. Excellent, just what I wanted. I've made a start with this and will report back. Man
It's sequential at the moment, although I'll do further tests with the -c (concurrency) option to bonnie++ Thank you very much: I will do further tests with these. Is the read_ahead_kb knob aware of
Author: Raghavendra D Prabhu <raghu.prabhu13@xxxxxxxxx>
Date: Wed, 1 Feb 2012 06:20:57 +0530
Hi, * On Tue, Jan 31, 2012 at 09:52:10PM +0000, Brian Candler <brian@xxxxxxxxxxxxxx> wrote: On Tue, Jan 31, 2012 at 09:52:05AM -0500, Christoph Hellwig wrote: You don't just read a single file at a t
Yeah, the voice coil actuator and spindle rotation limits the peak random seek rate of good 7.2k drive/controller combos to about 150/s. 15k drives do about 250-300 seeks/s max. Simple tool to test m
The default settings on this system are: noop [deadline] cfq (I think the one in brackets is the active one) 512 128 I did a series of tests where I increased either or both of those to 1024, but it
I've done a whole bunch of testing, which I won't describe in detail unless you're interested, but I've finally found out what's causing the sudden change in performance. With defaults, the files in
Not sure if you mentioned it somewhere before, but: a) how large is the filesystem? b) do use the inode64 mount option c) can you see the same good behaviour when using inode64 and small inodes (not
3TB, 32MB cache, 5940 RPM You stated you're writing 100,000 of these files across 1,000 directories, with Bonnie, then reading them back with dd in your custom script. You state this is similar to yo
3TB. No: the only mount options I've given are noatime,nodiratime. I created a fresh filesystem (/dev/sdh), default parameters, but mounted it with inode64. Then I tar'd across my corpus of 100K file
Although perversely, keeping all the inodes at one end of the disk does increase throughput with random reads, and also under high concurrency loads (for this corpus of ~65GB anyway, maybe not true f
Thanks for your suggestion, but unfortunately your maths isn't correct: 20M x 0.65MB = 13TB. And that's just one of many possible datasets like this. I'm aware that I'm working with low-performance d
Wow, you're right. How did I miss so many zeros? Got in hurry I guess. SSDs would fulfill criteria 1/2 but obviously not 3/4. Will you be using mdraid or hardware RAID across those 24 spindles? -- St