From: Mark Nelson <mark.nelson@inktank.com>
To: James Harper <james.harper@bendigoit.com.au>
Cc: Sylvain Munaut <s.munaut@whatever-company.com>,
"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Subject: Re: poor write performance
Date: Mon, 22 Apr 2013 07:01:25 -0500 [thread overview]
Message-ID: <51752695.9080205@inktank.com> (raw)
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B4F3637AD@BITCOM1.int.sbss.com.au>
On 04/22/2013 06:48 AM, James Harper wrote:
>>> My read speed is consistently around 40MB/second, and my write speed is
>>> consistently around 22MB/second. I had expected better of read...
>>
>> You may want to try increasing your read_ahead_kb on the OSD data disks
>> and see if that helps read speeds.
>>
>
> Default appears to be 128 and I was getting 40MB/second
> Increasing to 256 takes me up to 48MB/second
> Increasing to 512 takes me up to 53Mb/second
>
> Any further increases don't do anything that I can measure
>
> Is increasing read_ahead_kb good for general performance, or just for impressing people with benchmarks? If the kernel spent time reading ahead woult it hurt random read/write performance?
Potentially yes, but it depends on a lot of of factors. I suspect that
increasing it may be acceptable on modern drives, but you'll need to do
some testing to see how it goes in practice.
If anyone on the list knows how many sectors per track is typical for
modern 1-3TB drives I'm dying to know. That would help us guess at how
much data can be writen/read on average without imposing any head
movement. :)
>
> Thanks
>
> James
>
next prev parent reply other threads:[~2013-04-22 12:01 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-18 11:46 poor write performance James Harper
2013-04-18 12:15 ` Wolfgang Hennerbichler
2013-04-18 23:11 ` James Harper
2013-04-20 10:52 ` Harald Rößler
2013-04-20 11:12 ` James Harper
2013-04-20 21:04 ` Jeff Mitchell
2013-04-18 13:43 ` Mark Nelson
2013-04-18 16:46 ` Andrey Korolyov
2013-04-18 17:01 ` Mark Nelson
2013-04-18 23:23 ` James Harper
2013-04-19 7:21 ` James Harper
2013-04-19 7:30 ` James Harper
2013-04-19 11:09 ` James Harper
2013-04-19 14:50 ` Mark Nelson
2013-04-20 0:33 ` James Harper
2013-04-20 1:30 ` James Harper
2013-04-21 13:52 ` Mark Nelson
2013-04-22 5:32 ` James Harper
2013-04-22 11:34 ` Mark Nelson
2013-04-22 11:40 ` James Harper
2013-04-21 17:56 ` Sylvain Munaut
2013-04-21 23:04 ` James Harper
2013-04-22 8:34 ` Sylvain Munaut
2013-04-22 11:34 ` James Harper
2013-04-22 11:39 ` Mark Nelson
2013-04-22 11:48 ` James Harper
2013-04-22 12:01 ` Mark Nelson [this message]
2013-04-22 13:47 ` Mark Nelson
2013-04-22 15:20 ` Sage Weil
2013-04-22 15:35 ` Sylvain Munaut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51752695.9080205@inktank.com \
--to=mark.nelson@inktank.com \
--cc=ceph-devel@vger.kernel.org \
--cc=james.harper@bendigoit.com.au \
--cc=s.munaut@whatever-company.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.