CEPH osd restarts are taking too long a time
below is my ceph.conf
[osd]
osd_compact_leveldb_on_mount = false
leveldb_compact_on_mount = false
leveldb_cache_size=1073741824
leveldb_compression = false
osd_mount_options_xfs = "rw,noatime,inode64,logbsize=256k"
osd_max_backfills = 1
osd_recovery_max_
We're running a Ceph mimic (13.2.4) cluster which is predominantly used
for CephFS. We have recently switched to using multiple active MDSes to
cope with load on the cluster, but are experiencing problems with large
numbers of blocked requests when research staff run large experiments.
The erro
Did the time really cost on db compact operation?
or you can turn on debug_osd=20 to see what happens,
what about the disk util during start?
Nikhil R 于2019年3月28日周四 下午4:36写道：
>
> CEPH osd restarts are taking too long a time
> below is my ceph.conf
> [osd]
> osd_compact_leveldb_on_mount = false
>
Thanks huang for the reply.
Its is the disk compaction taking more time
the disk i/o is completely utilized upto 100%
looks like both osd_compact_leveldb_on_mount = false &
leveldb_compact_on_mount = false isnt working as expected on ceph v10.2.9
is there a way to turn off compaction?
Also, the re
Hi,
We are looking at extending one of our Ceph clusters, currently running
Luminous. The cluster is all SSD, providing RBD to Openstack, using 70
OSDs on 5 hosts.
We have a couple of projects kicking off that will need significantly more,
albeit slower storage. I am looking at speccing out so
Hi Uwe,
Am 28. Februar 2019 11:02:09 MEZ schrieb Uwe Sauter :
>Am 28.02.19 um 10:42 schrieb Matthew H:
>> Have you made any changes to your ceph.conf? If so, would you mind
>copying them into this thread?
>
>No, I just deleted an OSD, replaced HDD with SDD and created a new OSD
>(with bluestore).
ok, I tried doing ceph osd out on each of the 4 OSDs 1 by 1. I got it out
of backfill mode but still not sure if it'll fix anything. pg 10.2a still
shows state active+clean+inconsistent. Peer 8 is now
remapped+inconsistent+peering, and the other peer is
active+clean+inconsistent
On Wed, Mar 2
On Fri, Mar 29, 2019 at 7:54 AM solarflow99 wrote:
>
> ok, I tried doing ceph osd out on each of the 4 OSDs 1 by 1. I got it out of
> backfill mode but still not sure if it'll fix anything. pg 10.2a still shows
> state active+clean+inconsistent. Peer 8 is now
> remapped+inconsistent+peering
It seems like the split settings result the problem,
what about comment out those settings then see it still used that long
time to restart?
As a fast search in code, these two
filestore_split_multiple = 72
filestore_merge_threshold = 480
doesn't support online change.
Nikhil R 于2019年3月28日周四 下午6:
Hello all,
Having dug through the documentation and reading mailing list threads
until my eyes rolled back in my head, I am left with a conundrum
still. Do I separate the DB / WAL or not.
I had a bunch of nodes running filestore with 8 x 8TB spinning OSDs
and 2 x 240 GB SSDs. I had put the OS on
if i comment filestore_split_multiple = 72 filestore_merge_threshold = 480
in the ceph.conf wont ceph take the default value of 2 and 10 and we would
be in more splits and crashes?
in.linkedin.com/in/nikhilravindra
On Fri, Mar 29, 2019 at 6:55 AM huang jun wrote:
> It seems like the split se
On Fri, 29 Mar 2019 01:22:06 -0400 Erik McCormick wrote:
> Hello all,
>
> Having dug through the documentation and reading mailing list threads
> until my eyes rolled back in my head, I am left with a conundrum
> still. Do I separate the DB / WAL or not.
>
You clearly didn't find this thread, mo
Nikhil R 于2019年3月29日周五 下午1:44写道：
>
> if i comment filestore_split_multiple = 72 filestore_merge_threshold = 480
> in the ceph.conf wont ceph take the default value of 2 and 10 and we would be
> in more splits and crashes?
>
Yes, that aimed to make it clear what results in the long start time,
13 matches
Mail list logo
