That's the main reason we don't use autoscaler in production clusters. We don't want unattended pg splits and merging, so we always disable it. Just recently there was a similar question in slack, and everone who responded said basically the same. I guess you could try the bulk flag to see if that prevents Ceph from decreasing pg_num: ceph osd pool set <pool> bulk true Zitat von Martin Andersen <ceph-users@ceph.io>:
Hi all,
We have a 19.2.4 cluster with a Cinder pool (autoscale=warn) that keeps asking for num_pgs to be adjusted. This was recently set to 2048 (from 4096), and over this weekend it wanted to increase it again to 4096 - this was also done.
However, before the rebalance has even finished, it again informs that the num_pgs value is now too high, and asks for it to be reduced. This is within the span of under one hour.
ceph health detail HEALTH_WARN 1 pools have too few placement groups [WRN] POOL_TOO_FEW_PGS: 1 pools have too few placement groups Pool cinder-volumes has 2048 placement groups, should have 4096
ceph osd pool set cinder-volumes pg_num 4096 set pool 4 pg_num to 4096
ceph health detail HEALTH_WARN 1 pools have too many placement groups [WRN] POOL_TOO_MANY_PGS: 1 pools have too many placement groups Pool cinder-volumes has 4096 placement groups, should have 2048
Anyone else experiencing this behavior? We can obviously set the autoscaler to off for this pool, but there seems to either be a misconfiguration or errant default setting that should be addressed. This is a long-running pool that has had no recent config changes to pg assignment.
Also, for reference -
ceph config dump | grep pg global advanced mon_max_pg_per_osd 250 global advanced mon_pg_warn_max_object_skew 11.000000 global advanced mon_pg_warn_min_per_osd 10 global advanced mon_target_pg_per_osd 101 mgr advanced mgr/pg_autoscaler/log_level info
--Martin _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io