On 5/17/20 4:49 PM, Harald Staub wrote:
> tl;dr: this cluster is up again, thank you all (Mark, Wout, Paul
> Emmerich off-list)!
>
Awesome!
> First we tried to lower max- and min_pg_log_entries on a single running
> OSD, without and with restarting it. There was no effect. Maybe because
> of t
tl;dr: this cluster is up again, thank you all (Mark, Wout, Paul
Emmerich off-list)!
First we tried to lower max- and min_pg_log_entries on a single running
OSD, without and with restarting it. There was no effect. Maybe because
of the unclean state of the cluster.
Then we tried ceph-objects
Hi Harald,
Your cluster has a lot of objects per osd/pg and the pg logs will grow
fast and large because of this. The pg_logs will keep growing as long as
you're clusters pgs are not active+clean. This means you are now in a
loop where you cannot get stable running OSDs because the pg_logs tak
Hi Harald,
I was thinking just changing the config setting for the pglog length.
Having said that, if you only have 123 PGs per OSD max and 8.5GB of
pglog memory usage that sounds like a bug to me. Can you create a
tracker ticket with the ceph version and assoicated info? One of the
folks
Hi Mark
Thank you for your feedback!
The maximum number of PGs per OSD is only 123. But we have PGs with a
lot of objects. For RGW, there is an EC pool 8+3 with 1024 PGs with 900M
objects, maybe this is the problematic part. The OSDs are 510 hdd, 32 ssd.
Not sure, do you suggest to use somet
Hi Herald,
Changing the bluestore cache settings will have no effect at all on
pglog memory consumption. You can try either reducing the number of PGs
(you might want to check and see how many PGs you have and specifically
how many PGs on that OSD), or decrease the number of pglog entries pe
