On 5/30/12 7:41 AM, Stefan Priebe - Profihost AG wrote:
Hi Mark,
didn't had the time to answer your mails - but i will get on this one first.
Would you mind installing blktrace and running "blktrace -o test-3.4 -d
/dev/sdb" on the OSD node during a short (say 60s) test on 3.4?
sure no problem.
here it is:
http://www.mediafire.com/?6cw87btn7mzco25
Output:
=== sdb ===
CPU 0: 18075 events, 848 KiB data
CPU 1: 10738 events, 504 KiB data
CPU 2: 8639 events, 405 KiB data
CPU 3: 8614 events, 404 KiB data
CPU 4: 0 events, 0 KiB data
CPU 5: 0 events, 0 KiB data
CPU 6: 143 events, 7 KiB data
CPU 7: 0 events, 0 KiB data
Total: 46209 events (dropped 0), 2167 KiB data
Great, thanks. I'll try to look at the results later this morning. If
you want to look at them yourself you can open them with the blkparse
program (and seekwatcher too, though there is a bug in the src you have
to fix to make it work right)
If you could archive/send me the results, that might help us get an idea
of what is actually getting sent out to the disk. Your data disk
throughput on 3.0 looks pretty close to what I normally get (including
on 3.4). I'm guessing the issue you are seeing on 3.4 is probably not
the seek problem I mentioned earlier (unless something is causing so
many seeks that it more or less paralyzes the disk).
As i have a SSD i can't believe seeks can be a problem.
Ah, sorry. I forgot you were on SSD. Honestly I'm surpised that with
3.0 you weren't getting better performance. Something to look into once
we figure out why your 3.4 performance is so bad!
Stefan
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
