-Original Message-
From: ceph-users [mailto:ceph-users-boun...@lists.ceph.com] On Behalf Of
Mark Nelson
Sent: 27 May 2015 16:00
To: ceph-users@lists.ceph.com
Subject: Re: [ceph-users] Synchronous writes - tuning and some thoughts
about them?
On 05/27/2015 09:33 AM, Jan Schermer
Slow requests are not exactly tied to the PG number, but we were getting slow
requests whenever backfills or recoveries fired up - increasing the number of
PGs helped with this as the “blocks” of work are much smaller than before.
We have roughly the same number of OSDs as you but only one
Thanks, that’s it exactly.
But I think that’s really too much work for now, that’s why I really would like
to see a quick-win by using the local RBD cache for now - that would suffice
for most workloads (not too many people run big databases on CEPH now, those
who do must be aware of this).
We had to disable deep scrub or the cluster would me unusable - we need to turn
it back on sooner or later, though.
With minimal scrubbing and recovery settings, everything is mostly good. Turned
out many issues we had were due to too few PGs - once we increased them from 4K
to 16K everything
On 06/01/15 09:43, Jan Schermer wrote:
We had to disable deep scrub or the cluster would me unusable - we need to
turn it back on sooner or later, though.
With minimal scrubbing and recovery settings, everything is mostly good.
Turned out many issues we had were due to too few PGs - once we
On 05/29/2015 04:47 PM, Samuel Just wrote:
Many people have reported that they need to lower the osd recovery config
options to minimize the impact of recovery on client io. We are talking about
changing the defaults as follows:
osd_max_backfills to 1 (from 10)
osd_recovery_max_active to 3
For the sake of providing more clarity regarding the Ceph kernel module
situation on RHEL 7.0, I've removed all the files at
https://github.com/ceph/ceph-kmod-rpm and updated the README there.
The summary is that if you want to use Ceph's RBD kernel module on RHEL
7, you should use RHEL 7.1 or
Hi Somnath,
The workload will be mainly RDB (KRBD, LIBRBD) used for accessing the
cluster through an NFS gateway (since CephFS isn't quite production ready)
and for OpenStack, so it will be a mixed read/write workload.
Unfortunately it seems cache tiering doesn't gain that performance boost as
Hi,
I'm searching for actual packages for SLES11 SP3.
Via SMT-Updateserver it seems that there's only Version 0.80.8 available. Are
there
other package sources available (at least for Giant)?
What I want to do is mount ceph via rbd map natively instead mounting nfs from
another host
on which
Hi,
I ran a config diff, like this:
ceph --admin-daemon (...).asok config diff
There are the obvious things like the fsid and IP-ranges, but two
settings stand out:
- internal_safe_to_start_threads: true (default: false)
What does this do?
- leveldb_compression: false (default: true)
-
On Mon, Jun 1, 2015 at 6:53 AM, Erik Logtenberg e...@logtenberg.eu wrote:
Hi,
I ran a config diff, like this:
ceph --admin-daemon (...).asok config diff
There are the obvious things like the fsid and IP-ranges, but two
settings stand out:
- internal_safe_to_start_threads: true (default:
I just finished reading the CRUSH: Controlled, Scalable, Decentralized
Placement of Replicated Data” paper and it looks like the Tree algorithm is the
best compromise between mapping calculations and efficiency of reorganization.
I know the default is Straw and see that almost everyone is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sun, May 31, 2015 at 2:09 AM, Nick Fisk wrote:
Thanks for the suggestions. I will introduce the disk 1st and see if the
smart stats change from pending sectors to reallocated, if they don't then I
will do the DD and smart test. It will
Hi Mark, I don¹t suppose you logged latency during those tests, did you?
I¹m one of the folks, as Bryan mentioned, that advocates turning these
values down. I¹m okay with extending recovery time, especially when we are
talking about a default of 3x replication, with the trade off of better
client
I built a new crush map using crushtool with the following settings:
crushtool --outfn testcrush --build --num-osds 10 host straw 2 rack straw 2
default straw 0
This results in the following crushmap, to which I added a custom replication
rule myrtle.
When I run crushtool to test my new
On 06/01/2015 05:34 PM, Wang, Warren wrote:
Hi Mark, I don¹t suppose you logged latency during those tests, did you?
I¹m one of the folks, as Bryan mentioned, that advocates turning these
values down. I¹m okay with extending recovery time, especially when we are
talking about a default of 3x
I am trying to deploy a new ceph cluster and my monitors are not reaching
quorum. SELinux is off, firewalls are off, I can see traffic between the
nodes on port 6789 but when I use the admin socket to force a re-election
only the monitor I send the request to shows the new election in its logs.
On Mon, Jun 1, 2015 at 6:39 PM, Paul Von-Stamwitz
pvonstamw...@us.fujitsu.com wrote:
On Fri, May 29, 2015 at 4:18 PM, Gregory Farnum g...@gregs42.com wrote:
On Fri, May 29, 2015 at 2:47 PM, Samuel Just sj...@redhat.com wrote:
Many people have reported that they need to lower the osd recovery
18 matches
Mail list logo
