Hi,
On 08/19/2015 11:01 AM, Christian Balzer wrote:
Hello,
That's a pretty small cluster all things considered, so your rather
intensive test setup is likely to run into any or all of the following
issues:
1) The amount of data you're moving around is going cause a lot of
promotions from and
On 08/19/2015 10:58 AM, Nick Fisk wrote:
-Original Message-
From: ceph-users [mailto:ceph-users-boun...@lists.ceph.com] On Behalf Of
Jacek Jarosiewicz
Sent: 19 August 2015 09:29
To: ceph-us...@ceph.com
Subject: [ceph-users] requests are blocked - problem
I would suggest running the fio
Hi,
We are currently using 2 OSD hosts with SSDs to provide RBD backed volumes
for KVM hypervisors. This 'cluster' is currently set up in 'Location A'.
We are looking to move our hypervisors/VMs over to a new location, and will
have a 1Gbit link between the two datacenters. We can run Layer 2
On 08/18/2015 03:39 PM, Björn Lässig wrote:
For not having any dependencies in my cluster network, i want to use
only ipv6 link-local addresses on interface 'cephnet'.
cluster_network = fe80::%cephnet/64
RFC4007 11.7
The IPv6 addressing architecture [1] also defines the syntax of IPv6
-Original Message-
From: Jacek Jarosiewicz [mailto:jjarosiew...@supermedia.pl]
Sent: 19 August 2015 14:28
To: Nick Fisk n...@fisk.me.uk; ceph-us...@ceph.com
Subject: Re: [ceph-users] requests are blocked - problem
On 08/19/2015 10:58 AM, Nick Fisk wrote:
-Original
I would suspect that you will notice a significant slow down. Don't forget
that’s an extra 10ms on however long it already takes for each IO. Also when
the cluster does any sort of recovery it will likely get much worse.
-Original Message-
From: ceph-users
This simply depends on what your workload is. I know this is a non-anwer for
you but that's how it is.
Databases are the worst, because they tend to hit the disks with every
transaction, and the transaction throughput is in direct proportion to the
number of IOPS you can get. And the number of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
By default, all pools will use all OSDs. Each RBD, for instance, is
broken up into 4 MB objects and those objects are somewhat uniformly
distributed between the OSDs. When you add another OSD, the CRUSH map
is recalculated and the OSDs shuffle the
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Hi,
Thank you for the quick reply. However, we do have those exact settings
for recovery and it still strongly affects client io. I have looked at
various ceph logs and osd logs and nothing is out of the ordinary.
Here's an idea though, please tell me if I am wrong.
We use intel SSDs for
All the writes will go through the journal.
It may happen your SSDs are not preconditioned well and after a lot of writes
during recovery IOs are stabilized to lower number. This is quite common for
SSDs if that is the case.
Thanks Regards
Somnath
-Original Message-
From: J-P Methot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
You didn't specify your database, but if you are using mysql you can use:
[mysqld]
# Change disk flush to every second instead of after each transaction.
innodb_flush_log_at_trx_commit=2
to specify flushing the logs every X seconds instead of
Hi,
Our setup is currently comprised of 5 OSD nodes with 12 OSD each, for a
total of 60 OSDs. All of these are SSDs with 4 SSD journals on each. The
ceph version is hammer v0.94.1 . There is a performance overhead because
we're using SSDs (I've heard it gets better in infernalis, but we're not
If you are concerned about *client io performance* during recovery, use these
settings..
osd recovery max active = 1
osd max backfills = 1
osd recovery threads = 1
osd recovery op priority = 1
If you are concerned about *recovery performance*, you may want to bump this
up, but I doubt it will
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Probably the big question is what are the pain points? The most common
answer we get when asking folks what applications they run on top of Ceph is
everything!. This is wonderful, but not helpful when trying to figure out
what performance
Also, check if scrubbing started in the cluster or not. That may considerably
slow down the cluster.
-Original Message-
From: Somnath Roy
Sent: Wednesday, August 19, 2015 1:35 PM
To: 'J-P Methot'; ceph-us...@ceph.com
Subject: RE: [ceph-users] Bad performances in recovery
All the writes
Hi all,
We are experimenting with an idea to run OSD nodes in XenServer VMs. We
believe this could provide better flexibility, backups for the nodes etc.
For example:
Xenserver with 4 HDDs dedicated for Ceph.
We would introduce 1 VM (OSD node) with raw/direct access to 4 HDDs or 2
VMs (2 OSD
On Wed, 19 Aug 2015 10:02:25 +0100 Nick Fisk wrote:
-Original Message-
From: ceph-users [mailto:ceph-users-boun...@lists.ceph.com] On Behalf
Of Christian Balzer
Sent: 19 August 2015 03:32
To: ceph-users@lists.ceph.com
Cc: Nick Fisk n...@fisk.me.uk
Subject: Re:
Hello,
On Wed, 19 Aug 2015 15:27:29 +0200 Jacek Jarosiewicz wrote:
Hi,
On 08/19/2015 11:01 AM, Christian Balzer wrote:
Hello,
That's a pretty small cluster all things considered, so your rather
intensive test setup is likely to run into any or all of the following
issues:
1)
I kind of fixed it by creating a new journal in file instead of separate
partition, which probably caused some data loss, but at least allowed OSD
to start and join cluster. Backfilling is now in progress.
Old journal is still there on separate device, if it can help in
investigation. But this
Am 18.08.2015 um 15:43 schrieb Campbell, Bill:
Hey Stefan,
Are you using your Ceph cluster for virtualization storage?
Yes
Is dm-writeboost configured on the OSD nodes themselves?
Yes
Stefan
*From: *Stefan Priebe -
Hi!
I think, that renaming cluster - is not only mv config file. We try to change
name of test Hammer
cluster, created with ceph-deploy and got some issues.
In default install, naming of many parts are derived from cluster name. For
example, cephx keys are
stored not in
Thanks to all!
Everything worked like a charm:
1) Stopped the cluster (I guess it's faster than moving OSDs one by one)
2) Unmounted OSDs and fixed fstab entries for them
3) Renamed the MON and OSD folders
4) Renamed config file and keyrings, fixed paths to keyrings in config
5) Mounted OSDs back
-Original Message-
From: ceph-users [mailto:ceph-users-boun...@lists.ceph.com] On Behalf Of
Jacek Jarosiewicz
Sent: 19 August 2015 09:29
To: ceph-us...@ceph.com
Subject: [ceph-users] requests are blocked - problem
Hi,
Our setup is this:
4 x OSD nodes:
E5-1630 CPU
32 GB RAM
Hello,
That's a pretty small cluster all things considered, so your rather
intensive test setup is likely to run into any or all of the following
issues:
1) The amount of data you're moving around is going cause a lot of
promotions from and to the cache tier. This is expensive and slow.
2) EC
-Original Message-
From: ceph-users [mailto:ceph-users-boun...@lists.ceph.com] On Behalf Of
Christian Balzer
Sent: 19 August 2015 03:32
To: ceph-users@lists.ceph.com
Cc: Nick Fisk n...@fisk.me.uk
Subject: Re: [ceph-users] any recommendation of using EnhanceIO?
On Tue, 18 Aug
26 matches
Mail list logo
