From: Stefan Priebe <s.priebe@profihost.ag>
To: Gregory Farnum <greg@inktank.com>,
Dan Van Der Ster <daniel.vanderster@cern.ch>
Cc: "ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>,
Samuel Just <sam.just@inktank.com>
Subject: Re: default filestore max sync interval
Date: Tue, 29 Apr 2014 22:35:57 +0200 [thread overview]
Message-ID: <53600D2D.2070900@profihost.ag> (raw)
In-Reply-To: <CAPYLRzgEvr73iCYDyCvtrrF29iW1=PkEBEpr0GPeHpzRjG+hRw@mail.gmail.com>
H Greg,
Am 29.04.2014 22:23, schrieb Gregory Farnum:
> On Tue, Apr 29, 2014 at 1:10 PM, Dan Van Der Ster
> <daniel.vanderster@cern.ch> wrote:
>> Hi all,
>> Why is the default max sync interval only 5 seconds?
>>
>> Today we realized what a huge difference that increasing this to 30 or 60s can do for the small write latency. Basically, with a 5s interval our 4k write latency is above 30-35ms and once we increase it to 30s we can get under 10ms (using spinning disks for journal and data.)
>>
>> See the attached plot for the affect of this on a running cluster (the plot shows the max, avg, min write latency from a short rados bench every 10 mins). The change from 5s to 60s was applied at noon today. (And our journals are large enough, don't worry).
>>
>> In the interest of having sensible defaults, is there any reason not to increase this to 30s?
>
> If you've got reasonable confidence in the quality of your
> measurements across the workloads you serve, you should bump it up.
> Part of what might be happening here is simply that fewer of your
> small-io writes are running into a sync interval.
> I suspect that most users will see improvement by bumping up the
> limits and occasionally agitate to change the defaults, but Sam has
> always pushed back against doing so for reasons I don't entirely
> recall. :) (The potential for a burstier throughput profile?)
> -Greg
What is about those?
filestore queue max ops = 500
filestore_queue_committing_max_ops = 5000
filestore_queue_max_bytes = 419430400
filestore_queue_committing_max_bytes = 419430400
filestore_wbthrottle_xfs_bytes_start_flusher = 125829120
filestore_wbthrottle_xfs_bytes_hard_limit = 419430400
filestore_wbthrottle_xfs_ios_start_flusher = 5000
filestore_wbthrottle_xfs_ios_hard_limit = 50000
filestore_wbthrottle_xfs_inodes_start_flusher = 1000
filestore_wbthrottle_xfs_inodes_hard_limit = 10000
They should be adjusted too? right?
Stefan
next prev parent reply other threads:[~2014-04-29 20:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-29 20:10 default filestore max sync interval Dan Van Der Ster
2014-04-29 20:23 ` Gregory Farnum
2014-04-29 20:35 ` Stefan Priebe [this message]
2014-04-29 20:46 ` Gregory Farnum
2014-04-29 20:36 ` Stefan Priebe
2014-04-29 20:46 ` Dan van der Ster
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=53600D2D.2070900@profihost.ag \
--to=s.priebe@profihost.ag \
--cc=ceph-devel@vger.kernel.org \
--cc=daniel.vanderster@cern.ch \
--cc=greg@inktank.com \
--cc=sam.just@inktank.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.