We did look at the iostats of the disk, it was not saturated, but I
don't have any specific numbers right now as I don't have direct
access. But I'm open for more theories why waiting for 5 minutes lets
the MON sync immediately but waiting for more takes so much more time.
If necessary we'll need to investigate the debug logs during startup
and compare between two such events. But maybe someone already did
that which would save me quite some time. ;-)
Zitat von Konstantin Shalygin <k0ste@xxxxxxxx>:
This is a guess, the databases is like to swell. Especially the
Level DB's, can grow x2 and reduce tens of percent of total size.
This may be just another SST file creation, 1GB by default, Ii I
remember it right
Do you was looks to Grafana, about this HDD's utilization, IOPS?
k
Sent from my iPhone
On 7 Jul 2023, at 10:54, Eugen Block <eblock@xxxxxx> wrote:
Can you share some more details what exactly you mean? Do you mean
that if I restart a MON three times it goes into compaction
maintenance and that it's not related to a timing? We tried the
same on a different MON and only did two tests:
- stopping a MON for less than 5 minutes, starting it again, sync
happens immediately
- stopping a MON for more than 5 minutes, starting it again, sync
takes 15 minutes
This doesn't feel related to the payload size or keys option, but a
timing option.
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx
