ceph的参数

复制代码

auth_client_required = none
auth_cluster_required = none
auth_service_required = none
auth_supported = none
bluefs_buffered_io = True
bluestore_cache_size_hdd = 838860800
bluestore_cache_size_ssd = 838860800
bluestore_cache_trim_max_skip_pinned = 256
bluestore_csum_type = none
bluestore_max_blob_size_hdd = 524288
bluestore_min_alloc_size_hdd = 4096
bluestore_prefer_deferred_size_hdd = 2048
bluestore_rocksdb_cf = False
bluestore_rocksdb_options = hik_compaction_delay_ms=600,num_levels=7,compression=kNoCompression,max_write_buffer_number=64,min_write_buffer_number_to_merge=32,recycle_log_file_num=64,write_buffer_size=4194304,target_file_size_base=67108864,writable_file_max_buffer_size=0,compaction_readahead_size=2097152,level0_file_num_compaction_trigger=16,level0_slowdown_writes_trigger=128,level0_stop_writes_trigger=256,bytes_per_sync=4194304,wal_bytes_per_sync=1048576,optimize_filters_for_hits=1,bloom_locality=1,skip_stats_update_on_db_open=true,max_subcompactions=1,max_bytes_for_level_base=4831838208,compaction_pri=kMinOverlappingRatio,max_total_wal_size=1073741824
bluestore_shard_finishers = True
client_die_on_failed_remount = False
client_dirsize_rbytes = False
client_oc_max_dirty = 41943040
client_oc_max_dirty_age = 2
client_oc_max_objects = 60
client_oc_size = 104857600
client_oc_target_dirty = 4194304
client_reconnect_stale = True
cluster_network = 172.16.111.0/24
debug_asok = 0/0
debug_auth = 0/0
debug_bdev = 0/0
debug_bluefs = 0/0
debug_bluestore = 0/0
debug_civetweb = 0/0
debug_compressor = 0/0
debug_crush = 0/0
debug_crypto = 0/0
debug_dpdk = 0/0
debug_eventtrace = 0/0
debug_filestore = 0/0
debug_finisher = 0/0
debug_fuse = 0/0
debug_heartbeatmap = 0/0
debug_javaclient = 0/0
debug_journal = 0/0
debug_kinetic = 0/0
debug_kstore = 0/0
debug_leveldb = 0/0
debug_mds = 0/0
debug_mds_balancer = 0/0
debug_mds_locker = 0/0
debug_mds_log = 0/0
debug_mds_log_expire = 0/0
debug_mds_migrator = 0/0
debug_memdb = 0/0
debug_mgr = 0/0
debug_mgrc = 0/0
debug_mon = 0/0
debug_osd = 0/0
debug_paxos = 0/0
debug_perfcounter = 0/0
debug_rgw = 0/0
debug_rocksdb = 0/0
debug_throttle = 0/0
debug_xio = 0/0
fsid = ed347113-e8bd-4e55-865c-ef663c516a5a
ipversion = ipv4
mds_beacon_grace = 6
mds_beacon_interval = 2
mds_reconnect_timeout = 2
mds_session_blacklist_on_timeout = False
mds_tick_interval = 2
mempool_debug = True
mgr_disabled_modules = diskprediction_local
mgr_stats_threshold = 0
mon_allow_pool_delete = True
mon_allow_pool_size_one = True
mon_client_hunt_interval = 2
mon_client_hunt_interval_backoff = 1
mon_client_hunt_interval_max_multiple = 5
mon_client_hunt_interval_min_multiple = 1
mon_client_hunt_parallel = 5
mon_client_ping_interval = 2
mon_client_ping_timeout = 7
mon_clock_drift_allowed = 60
mon_clock_drift_warn_backoff = 60
mon_compact_on_trim = False
mon_data_avail_warn = 15
mon_election_timeout = 5
mon_health_data_update_interval = 20
mon_host = 172.16.111.11:6789,172.16.111.12:6789,172.16.111.13:6789
mon_initial_members = node1,node2,node3
mon_lease = 3
mon_lease_ack_timeout_factor = 2
mon_max_pg_per_osd = 1024000
mon_osd_adjust_down_out_interval = False
mon_osd_adjust_heartbeat_grace = False
mon_osd_auto_mark_in = True
mon_osd_backfillfull_ratio = 0.93
mon_osd_destroyed_out_interval = 94608000
mon_osd_down_out_interval = 2000
mon_osd_full_ratio = 0.97
mon_osd_min_down_reporters = 2
mon_osd_min_in_ratio = 0.3
mon_osd_nearfull_ratio = 0.9
mon_osd_pool_ec_fast_read = True
mon_osd_report_timeout = 25
mon_osd_reporter_subtree_level = rack
mon_sync_max_payload_size = 10485760
mon_sync_timeout = 300
mon_tick_interval = 2
mon_warn_pg_not_deep_scrubbed_ratio = 0
mon_warn_pg_not_scrubbed_ratio = 0
ms_async_op_threads = 16
ms_async_set_affinity = False
ms_bind_ipv4 = True
ms_bind_ipv6 = False
ms_dispatch_throttle_bytes = 419430400
ms_max_backoff = 2
objecter_inflight_op_bytes = 524288000
objecter_inflight_ops = 5120
osd_allocator_update_disable = True
osd_beacon_report_interval = 6
osd_client_message_cap = 1000000
osd_client_message_size_cap = 4194304000
osd_client_watch_timeout = 20
osd_crush_update_on_start = False
osd_failsafe_full_ratio = 0.99
osd_force_recovery_pg_log_entries_factor = 1
osd_heartbeat_grace = 20
osd_heartbeat_interval = 6
osd_max_backfills = 4
osd_max_pg_log_entries = 3000
osd_max_scrubs = 2
osd_max_write_size = 256
osd_memory_target = 939524096
osd_min_pg_log_entries = 100
osd_mon_heartbeat_interval = 3
osd_mon_report_interval_max = 20
osd_op_complaint_time = 10
osd_op_num_threads_per_shard_hdd = 1
osd_op_queue = wpq
osd_op_queue_cut_off = low
osd_pg_log_dups_tracked = 100
osd_pg_stat_report_interval_max = 20
osd_pool_default_crush_rule = -1
osd_pool_default_pg_autoscale_mode = off
osd_recovery_max_active = 1
osd_recovery_max_single_start = 1
osd_recovery_op_priority = 1
osd_recovery_priority = 1
osd_recovery_sleep = 0.4
osd_scrub_chunk_max = 25
osd_scrub_chunk_min = 5
osd_scrub_during_recovery = True
osd_scrub_sleep = 0.01
osd_target_pg_log_entries_per_osd = 300000
paxos_stash_full_interval = 10
public_network = 172.16.111.0/24
rbd_cache = False
rbd_concurrent_management_ops = 50
rbd_read_from_replica_policy = localize
rbd_read_from_replica_policy_location = hci_default
rbd_remove_sleep_ms = 0
rbd_snap_rollback_sleep_ms = 0
rocksdb_block_size = 4096
rocksdb_cache_shard_bits = 1

解释

好的。你这份内容本质上是 Ceph 集群的配置参数清单（类似 ceph.conf 的全集展开） 。参数数量非常多，如果逐个"长篇大论"会失去可读性，因此我会 严格做到"每一个参数都解释"，但每个参数只给两句话：

一句通俗解释（偏运维直觉）
一句专业解释（偏 Ceph 内部机制）

并且 按模块分组，这样你可以快速定位、整体理解，而不是被参数淹没。

下面所有参数均来自你给出的配置文件内容。

一、认证 / 客户端通用参数

`auth_client_required = none`

通俗：客户端连 Ceph 时不强制使用认证。
专业：指定客户端与集群通信时所需的 CephX 认证模式，none 表示关闭认证校验。

`auth_cluster_required = none`

通俗：集群内部节点之间不强制认证。
专业：控制 MON / OSD / MDS 等守护进程之间的 CephX 认证策略。

`auth_service_required = none`

通俗：服务端也不要求认证。
专业：指定服务端接受连接时所要求的认证级别。

二、BlueStore / BlueFS（OSD 存储引擎）

`bluefs_buffered_io = True`

通俗：BlueFS 读写时使用缓存。
专业：控制 BlueFS 是否使用操作系统 page cache 进行缓冲 I/O。

`bluestore_cache_size_hdd = 838860800`

通俗：为 HDD OSD 分配约 800MB 内存缓存。
专业：设置 BlueStore 在 HDD 场景下的缓存大小（字节）。

`bluestore_cache_size_ssd = 838860800`

通俗：为 SSD OSD 分配约 800MB 内存缓存。
专业：设置 BlueStore 在 SSD 场景下的缓存大小。

`bluestore_cache_trim_max_skip_pinned = 256`

通俗：缓存回收时最多跳过 256 个被固定的对象。
专业：控制 cache trim 阶段对 pinned buffer 的最大跳过数量。

`bluestore_csum_type = none`

通俗：不对数据块做校验和。
专业：指定 BlueStore 数据校验算法，none 表示关闭数据校验。

`bluestore_max_blob_size_hdd = 524288`

通俗：HDD 上单个数据块最大 512KB。
专业：限制 HDD 设备上 BlueStore blob 的最大尺寸。

`bluestore_min_alloc_size_hdd = 4096`

通俗：HDD 最小分配单位是 4KB。
专业：指定 HDD 上 BlueStore 的最小分配粒度。

`bluestore_prefer_deferred_size_hdd = 2048`

通俗：小于 2KB 的写入尽量延迟合并。
专业：设置 BlueStore 延迟写入（deferred write）的偏好阈值。

`bluestore_rocksdb_cf = False`

通俗：不启用 RocksDB 的列族优化。
专业：控制是否为 BlueStore 元数据启用 RocksDB Column Family。

`bluestore_rocksdb_options = ...`

通俗：一大堆 RocksDB 的性能调优参数。
专业：详细配置 BlueStore 内部 RocksDB 的 compaction、缓存、WAL、level 结构等。

`bluestore_shard_finishers = True`

通俗：让后台任务并行执行。
专业：启用分片 finisher 线程以提升 BlueStore 异步处理能力。

三、客户端缓存（Object Cache）

`client_oc_size = 104857600`

通俗：客户端最多用 100MB 做对象缓存。
专业：设置客户端 Object Cache 的总大小（字节）。

`client_oc_max_dirty = 41943040`

通俗：最多允许 40MB 脏数据没写回。
专业：限制客户端缓存中脏对象的最大字节数。

`client_oc_target_dirty = 4194304`

通俗：目标脏数据量是 4MB。
专业：触发回写的脏数据目标阈值。

`client_oc_max_dirty_age = 2`

通俗：脏数据最多缓存 2 秒。
专业：指定脏缓存对象允许存在的最长时间（秒）。

`client_oc_max_objects = 60`

通俗：缓存中最多放 60 个对象。
专业：限制 Object Cache 中对象数量。

`client_reconnect_stale = True`

通俗：断线重连时允许旧连接恢复。
专业：控制客户端是否允许使用 stale session 进行重连。

四、网络配置

`public_network = 172.16.111.0/24`

通俗：集群对外通信走这个网段。
专业：定义 Ceph 公共网络，用于客户端与集群通信。

`cluster_network = 172.16.111.0/24`

通俗：集群内部复制也走这个网段。
专业：定义 OSD 之间用于复制和心跳的集群网络。

`ipversion = ipv4`

通俗：只使用 IPv4。
专业：指定 Ceph 网络协议栈的 IP 版本。

五、Monitor（MON）参数

`mon_host = 172.16.111.11:6789,...`

通俗：MON 节点地址列表。
专业：指定集群中 Monitor 的监听地址和端口。

`mon_initial_members = node1,node2,node3`

通俗：最初的 MON 成员。
专业：定义初始化 Paxos quorum 的 Monitor 节点集合。

`mon_allow_pool_delete = True`

通俗：允许删除存储池（危险）。
专业：控制是否允许执行 pool delete 操作。

`mon_osd_full_ratio = 0.97`

通俗：磁盘用到 97% 就算满。
专业：超过该比例时 OSD 被标记为 full，停止写入。

`mon_osd_nearfull_ratio = 0.9`

通俗：90% 时开始预警。
专业：定义 nearfull 阈值，用于健康告警。

（其余 mon_* 参数本质都围绕 心跳、选举、OSD 状态判断、Paxos 同步 ，如果你愿意我可以单独给你画一张 MON 状态机示意图。）

六、OSD 核心参数

`osd_memory_target = 939524096`

通俗：每个 OSD 目标使用约 896MB 内存。
专业：OSD 进程的动态内存控制目标值。

`osd_max_backfills = 4`

通俗：最多同时做 4 个回填任务。
专业：限制 OSD 同时进行 backfill 的 PG 数量。

`osd_recovery_max_active = 1`

通俗：一次只恢复一个 PG。
专业：限制同时进行的恢复操作数量。

`osd_scrub_during_recovery = True`

通俗：恢复时也允许做 scrub。
专业：控制 scrub 是否与 recovery 并行执行。

`osd_op_queue = wpq`

通俗：使用加权优先队列处理请求。
专业：指定 OSD 内部请求调度队列算法（Weighted Priority Queue）。

七、RBD（块存储）

`rbd_cache = False`

通俗：RBD 不使用本地缓存。
专业：控制 RBD 客户端是否启用读写缓存。

`rbd_read_from_replica_policy = localize`

通俗：尽量从本地副本读数据。
专业：定义 RBD 从副本读取的策略，以降低跨节点延迟。

八、调试参数（debug_*）

`debug_osd = 0/0`（以及所有 debug_*）

通俗：不输出调试日志。
专业：指定模块的日志级别（前台/后台），0 表示关闭。

总体理解一句话总结

这份配置整体是：关闭认证、偏性能调优、偏测试或内网环境使用的 Ceph 集群配置，重点在 BlueStore + RocksDB + OSD 恢复限流。

如果你愿意，下一步我可以帮你做三件事之一（任选）：

哪些参数是"生产环境必须改的"
哪些参数对性能影响最大（前 10 个）
画一张 Ceph：Client → MON → OSD → BlueStore 的参数作用路径图

你直接告诉我选哪个。

下面把你列出的 BlueFS / BlueStore / RocksDB 这组参数逐个"再深入一层"讲清楚：它们分别影响什么路径（数据/元数据）、带来什么收益、典型副作用是什么、以及在 HDD/SSD 场景下如何理解取值。

1) `bluefs_buffered_io = True`

这参数到底控制什么

BlueFS 是什么 ：BlueStore 会把一部分"元数据/日志"放在 RocksDB/WAL 上，而 RocksDB 的文件（SST、WAL 等）最终由 BlueFS 管理并落盘到你的 DB 设备（通常是 SSD/NVMe）。
buffered I/O 是什么 ：指 通过操作系统页缓存（page cache） 走普通文件 I/O；相对的是 direct I/O（绕开页缓存，直接与块设备交互）。

开 `True` 的效果（你现在的配置）

优点（通俗）：系统会帮你"先放内存里攒一攒再写盘"，读的时候也能从内存里命中，通常更快。
优点（专业）：page cache 能吸收小随机写、合并写入、提高 read hit rate；对 RocksDB 这种频繁读写小块文件的负载，延迟更容易变平滑。

潜在副作用

内存占用更不可控：页缓存属于内核管理，可能导致 OSD 进程自身可用内存变少、抖动（特别是 OSD 多、内存紧时）。
双层缓存 ：BlueStore 自己也有缓存（后面两个 bluestore_cache_size_*），再叠加 page cache，可能出现"缓存堆叠"带来的效率不高或难以预估的内存压力。

适用建议（经验规律）

内存充裕 + 追求低延迟/高吞吐 ：True 通常更友好。
内存很紧 / OSD 很多 ：可能更倾向 False（让 I/O 更可控），但这通常需要结合 Ceph 版本、DB 设备能力与实际压测决定。

2) `bluestore_cache_size_hdd = 838860800`（约 800 MiB）

它控制的"缓存"是什么

这是 BlueStore 在 OSD 进程内的缓存预算（更准确地说是 BlueStore 的 memory cache 目标规模之一），主要服务于：

数据读写路径中的 buffer/cache
元数据访问的缓存（取决于版本与配置组合）

你可以把它理解为：OSD 自己"留一笔内存"用来缓存热点数据和减少磁盘 I/O。

为什么分 HDD / SSD 两套

Ceph 认为不同介质的特性不同：

HDD：随机 I/O 极慢，更依赖缓存来把随机读写变少。
SSD：随机 I/O 相对更强，缓存的边际收益可能更小，但仍然有价值（尤其是读热点、写放大控制、元数据路径等）。

调大/调小会怎样

调大
- 好处：读命中率更高、对 HDD 随机读更友好、写入更平滑。
- 风险：OSD 内存更吃紧，容易触发系统内存压力，导致抖动甚至 OOM（尤其同时还开了 bluefs_buffered_io=True 的情况下）。
调小
- 好处：内存更稳、更容易做容量规划。
- 代价：HDD 场景性能下降明显（更多随机读落到盘上），尾延迟更差。

关键点

这个参数不是"越大越好"，而是一个 在"命中率收益"和"内存压力/抖动"之间找平衡 的调参点。

3) `bluestore_cache_size_ssd = 838860800`（约 800 MiB）

与 HDD 的区别理解

对 SSD/NVMe 来说，缓存仍然能带来收益，但往往主要体现在：
- 热点读的命中率
- 减少重复解压/校验/对象处理开销（视配置与版本）
- 降低尾延迟（尤其混合负载）

常见取值思路

如果你的 OSD 全是 SSD/NVMe，很多集群会把这类缓存 设得比 HDD 场景"相对保守"（因为 SSD 的随机 I/O 本身更强）。
但你这里 HDD/SSD 都给了同样 800MB，说明你更偏向"让 OSD 进程缓存更积极"，前提是机器内存要跟得上。

4) `bluestore_cache_trim_max_skip_pinned = 256`

"pinned" 是什么（直观解释）

在 BlueStore 缓存里，有些 buffer 会被"固定住"（pinned），表示它正在被使用、暂时不能回收。
当系统要 trim（回收）缓存 的时候，如果碰到 pinned 的，就只能跳过继续找能回收的。

这个参数做什么

它限制：回收时最多连续跳过多少个 pinned buffer。
目的：避免 trim 线程在大量 pinned 的情况下"无止境扫描"，浪费 CPU。

调参影响

值太小
- 可能导致"回收不够积极"：刚好遇到一片 pinned，就提前停止，缓存压力可能得不到缓解。
值太大
- 回收时扫描成本上升：trim 线程可能花更多 CPU 在"找可回收对象"，对高负载时的抖动不利。

为什么 256 常见

这是一个典型的工程折中值：给回收一点"坚持寻找"的空间，但不让它无限消耗 CPU。

5) `bluestore_csum_type = none`

它真正影响什么

BlueStore 默认可以对写入的数据块做 校验和（如 crc32c 等），读出来时验证，发现 silent corruption 可以报错或触发修复链路（视上层机制）。
你这里 none：完全关闭数据校验。

好处

性能：省 CPU（尤其高吞吐写入+读取校验时），延迟更低。
吞吐：在 CPU 成为瓶颈时，关校验可能明显提升。

风险（这是高风险项）

静默数据损坏更难被发现：磁盘/控制器/内存/传输链路导致的 bit rot 或 silent corruption，可能不会被及时识别。
对分布式存储来说，校验常常是"最后一道防线"。关闭意味着你把可靠性更多押在硬件与其它机制上。

适用场景

更常见于 测试环境/性能压测，或用户明确接受风险的场景。
生产环境通常会谨慎对待：要么不关，要么配合更强的数据保护与巡检策略。

6) `bluestore_max_blob_size_hdd = 524288`（512 KiB）

blob 是什么

在 BlueStore 中，数据会以 blob 作为一类组织单元（可理解为"在底层块设备上连续存放的一段数据集合/容器"），它会影响：

写入聚合程度
空间碎片
读写放大特性

这个参数的含义

限制 HDD 场景下单个 blob 的最大大小（512KB）。
目标：让 BlueStore 在 HDD 上的分配/写入行为更符合 HDD 的最佳 I/O 粒度，避免过大 blob 带来的管理/回收成本，也避免过小导致碎片/元数据膨胀。

调参权衡

更大 blob
- 可能更接近顺序写，对 HDD 友好；但回收/重写时粒度更大，可能增加写放大。
更小 blob
- 更灵活、碎片控制可能更细；但元数据与分配次数增加，管理开销变大。

7) `bluestore_min_alloc_size_hdd = 4096`（4 KiB）

它是"最小分配粒度"

在 HDD 上，BlueStore 分配空间的最小单位是 4KB。
简单说：哪怕你只写 1KB，也至少要占用 4KB 的底层空间（从分配角度）。

影响点

空间放大：小对象/小写入会浪费空间（内部碎片）。
I/O 模型：4KB 是常见的块粒度，也更贴近多数磁盘/文件系统的基本对齐要求，能避免大量非对齐写带来的额外开销。

为什么不是更大（例如 64KB）

更大粒度会减少分配次数，但会显著增加空间放大与小 I/O 的浪费。
HDD 下 4KB 是一个常见折中：兼顾对齐与空间效率。

8) `bluestore_prefer_deferred_size_hdd = 2048`（2 KiB）

"deferred write" 直观解释

deferred（延迟）写：先把小写入缓存在内存/日志中，等合适时机再落到主数据区域，尽量把随机小写"攒成更顺序、更大块"的写。

这个参数做什么

设定一个阈值：小于该大小的写入更倾向走 deferred 路径。
你设置 2KB：表示 非常小的写更积极地延迟合并，这在 HDD 上通常能改善随机写的代价。

权衡

优点：减少 HDD 随机写、提升吞吐、降低写延迟抖动。
代价：更多数据短时间停留在缓存/日志路径，可能在崩溃恢复、回放、以及后台整理时引入额外工作量（具体取决于版本实现与工作负载）。

9) `bluestore_rocksdb_cf = False`

Column Family（列族）是什么

RocksDB 的 Column Family 可以把不同类型的键值数据拆成多个逻辑"表"，从而：

允许不同 CF 使用不同的 compaction/缓存策略
降低某类数据的 compaction 对另一类数据的干扰

设为 False 的含义

BlueStore 元数据在 RocksDB 内不做 CF 级别拆分（或不启用 CF 优化路径）。
实际效果通常是：配置更简单，行为更统一，但优化空间更小。

为什么有人会关

复杂度：CF 会增加调优维度与排障复杂度。
稳定性/兼容性考虑：某些版本或特定场景下，用户会选择更"保守可预期"的 RocksDB 使用方式。

10) `bluestore_rocksdb_options = ...`（这组最关键也最复杂）

你这里的 options 很长，我不逐个"贴公式式解释"，而是按 四类关键旋钮 解释，让你能看懂它在调什么：

A. MemTable / 写缓冲（写入先落内存）

write_buffer_size=4194304（4MB）：单个 memtable 的大小。
max_write_buffer_number=64 / min_write_buffer_number_to_merge=32：允许积累很多 memtable，再合并/刷盘。
含义：你这是典型的"允许堆很多内存写缓冲，减少刷盘频率，追求吞吐"。

B. LSM 层级与 compaction（后台整理/合并）

num_levels=7：LSM 树层数。
level0_file_num_compaction_trigger=16、level0_slowdown_writes_trigger=128、level0_stop_writes_trigger=256
含义：L0 文件很多了才开始 compaction；非常能"扛写入"，但一旦后台跟不上，容易出现写入节流甚至暂停写入的门槛（这里门槛设得很高，偏吞吐策略）。
compaction_pri=kMinOverlappingRatio：选择 compaction 的策略倾向减少重叠。
max_subcompactions=1：限制并行 compaction。
含义：compaction 更保守并行度，可能是为了避免 compaction 抢太多 IO/CPU。

C. WAL 与同步（写入持久化路径）

max_total_wal_size=1073741824（1GB）：WAL 总量上限。
wal_bytes_per_sync=1048576、bytes_per_sync=4194304：控制顺序写的同步粒度，减少抖动。
含义：在吞吐与稳定性之间做折中，尽量用"分段同步"平滑延迟。

D. 过滤器/布隆过滤器与读优化

optimize_filters_for_hits=1、bloom_locality=1
含义：更偏向读命中优化，减少无谓磁盘访问。

总体评价：你这套 RocksDB 选项整体风格非常鲜明------偏吞吐、允许堆积、延迟 compaction、降低压缩开销（compression=kNoCompression）。这通常用于追求性能或特定硬件/场景下的配置，但对"后台整理跟不上时的风险"需要监控（例如 compaction backlog、WAL 膨胀、写入延迟飙升）。

11) `bluestore_shard_finishers = True`

finisher 是什么

在 Ceph/OSD 内部，很多操作会变成"异步回调任务"，由 finisher 线程池负责执行（例如完成通知、清理、后处理等）。

shard 的含义

shard_finishers=True：把 finisher 拆成多个分片队列/线程，减少锁争用与队列拥塞。
直观理解：从"一个收银台"变成"多个收银台"，高并发时更不容易排长队。

什么时候收益大

高 IOPS、小对象、回调频繁 的负载（例如大量 RBD 随机 IO、小块写、元数据活动很重），更容易看到收益。
代价一般是：线程更多、调度更复杂，但通常是值得的。

这组参数放在一起，你可以这样理解"整体目标"

这 11 个参数整体在做一件事：
让 BlueStore 在 HDD 场景尽量减少随机写、让 RocksDB/BlueFS 更能吞吐、同时用较大的缓存与较高的 compaction 阈值来换性能。

其中"风险/敏感项"通常集中在两类：

内存相关 （bluefs_buffered_io + bluestore_cache_size_* 叠加导致内存压力不可控）
可靠性相关 （bluestore_csum_type=none）

如果你希望我继续更"落地"，我可以基于这 11 个参数再给你两张清单（你选一个方向即可，不需要再补信息）：

"生产环境建议值/风险等级"表（哪些必须谨慎、哪些可放心开）
"性能调优路线图"（你要提升吞吐/降低延迟/减少抖动分别优先看哪些指标与参数联动）

很好，这一组参数全部属于 Ceph Client 侧的 Object Cache（对象缓存）与会话重连机制 ，它们不在 OSD 上生效，而是在客户端进程（如 librados / RBD / RGW client / CephFS client）中生效 。

下面我会 比你之前看到的解释"再下沉一层"，重点讲清楚：

它们在 I/O 路径中的位置
彼此之间 如何联动
为什么不是随便设的
常见 误解点和风险点

一、先给你一张"脑内结构图"（非常重要）

在讲单个参数前，先统一一个模型，否则容易混：

复制代码

应用程序
   ↓
Ceph Client（librados / RBD / CephFS）
   ↓
【Object Cache（你这组参数控制的地方）】
   ├─ clean objects（干净对象）
   ├─ dirty objects（已修改但未写回）
   ↓
网络 → OSD → BlueStore

👉 这组参数控制的是：客户端在"真正把数据发给 OSD 之前"，能在本地内存里缓存多少、缓存多久、怎么触发回写。

二、`client_oc_size = 104857600`（100MB）

深层含义

这是 客户端 Object Cache 的"总预算上限"，包括：

干净对象（只读缓存）
脏对象（写后未提交到 OSD 的数据）

它不是"建议值"，而是一个硬性上限（soft + hard 结合）。

它真正限制的是什么

不是单个对象大小
不是单次 I/O
而是：客户端允许"拖住"在本地内存里的数据总量

调大 / 调小的真实影响

调大
- 写入可以在客户端"憋更久"，减少网络往返
- 顺序写、覆盖写性能明显提升
- 代价：客户端进程更吃内存，崩溃时潜在丢数据窗口变大（未提交的数据）
调小
- 更"实时"地把数据推给 OSD
- 延迟更稳定，但吞吐下降明显（尤其小 I/O）

一个关键认知

client_oc_size 决定了：客户端在多大程度上"像一个 write-back cache"。

三、`client_oc_max_dirty = 41943040`（40MB）

它和 `client_oc_size` 的关系

client_oc_size：缓存总量
client_oc_max_dirty：其中"脏数据"最多允许占多少

也就是说：

你允许最多 100MB 缓存，但其中只有 40MB 可以是"没写回 OSD 的数据"。

为什么要单独限制脏数据

脏数据 = 还没持久化的数据
一旦客户端进程 crash、断电、OOM，这部分可能丢失（视上层语义）

调参背后的权衡

值大
- 写入更"激进"
- 吞吐高，延迟低
- 风险：客户端故障导致更多未提交数据丢失
值小
- 写入更"保守"
- 数据更快到 OSD
- 性能下降明显（尤其 RBD 随机写）

非常常见的误区

❌ 以为它限制的是"单个对象脏大小"

✅ 实际是 所有对象的脏数据总和

四、`client_oc_target_dirty = 4194304`（4MB）

这是"软目标"，不是硬限制

client_oc_max_dirty：红线
client_oc_target_dirty：理想值 / 回写目标

它在做什么

当脏数据 超过 target 时：

客户端会 主动启动回写
尝试把脏数据压回到 target 附近

当脏数据 还没到 max：

不会强制阻塞写
只是"后台慢慢写"

用一句工程语言概括

target 是"日常运行点"，max 是"紧急刹车线"。

为什么你这里差距这么大（4MB vs 40MB）

这是一个 非常典型的"性能优先型配置"：

平时：保持较小脏集（利于稳定性）
峰值：允许短时间写爆（利于吞吐）

五、`client_oc_max_dirty_age = 2`（秒）

它解决的不是"大小"，而是"时间"

即使脏数据 没超过 max / target，只要：

某个脏对象 存在时间 ≥ 2 秒

👉 也必须被写回 OSD

为什么需要这个参数

如果只靠大小控制，会出现：

小量写入
长时间不触发回写
数据"悬在客户端内存里"

这个参数提供了一个 时间维度的"兜底机制"。

实际效果

值小（如 1--2 秒）
- 数据更快落盘
- 更接近同步语义
值大
- 写入更像"异步缓存"
- 崩溃窗口更大

非常重要的一点

这是 client 侧"数据新鲜度"的最后保障机制。

六、`client_oc_max_objects = 60`

它限制的不是"字节"，而是"对象数量"

即使：

每个对象很小
总字节数没超

只要：

缓存对象数 > 60

👉 就会触发回收 / 写回 / 驱逐

为什么需要"对象数"这个维度

Ceph 是 对象存储内核：

大量小对象 = 元数据压力大
LRU / 哈希 / 索引管理成本上升

这个参数用于：

防止"小对象风暴"把客户端缓存结构撑爆
控制管理复杂度，而不仅是内存

调参建议理解

对象很大（如 RBD 顺序写）：这个值影响不大
对象很多（如 CephFS 小文件、RGW 小对象）：这个值非常敏感

七、`client_reconnect_stale = True`

什么是 stale session

当客户端：

网络抖动
OSD / MON 短暂不可达
客户端 TCP 连接断开

原来的 session 在服务端看来是 "可能已失效（stale）"。

这个参数的作用

True：允许客户端"带着旧 session 信息回来续命"
False：必须建立全新 session

开启的好处

网络抖动时：
- I/O 不容易失败
- RBD / CephFS 应用更稳定
对短暂网络问题非常友好

潜在风险

在极端情况下（网络分区 + 多副本写）：
- 可能增加状态一致性处理复杂度
- 需要依赖 Ceph 的租约 / epoch / fencing 机制兜底

实际工程结论

在绝大多数现代 Ceph 集群中，这是"推荐开启"的选项。

八、把这 6 个参数放在一起，你应该这样理解

它们共同定义了 客户端的"写回缓存策略"：

维度	参数
缓存总容量	`client_oc_size`
最大风险窗口	`client_oc_max_dirty`
日常运行点	`client_oc_target_dirty`
时间兜底	`client_oc_max_dirty_age`
对象规模控制	`client_oc_max_objects`
连接健壮性	`client_reconnect_stale`

一句话总结它们的设计哲学：

在客户端侧，用"大小 + 时间 + 对象数"三把尺子，控制性能、内存和数据安全之间的平衡。

如果你愿意，下一步我可以继续帮你做三件"更实战"的事之一（任选）：

结合 RBD / CephFS / RGW 场景，告诉你这组参数是否"合理"
给你一个"写入时序图"，精确画出 target / max / age 是什么时候起作用的
告诉你哪些 client_oc 参数最容易被误调、最容易引发线上问题

你直接选编号即可。

下面我按 "OSD 资源控制 → 恢复/回填 → 请求调度 → RBD 行为 → 调试体系" 这个顺序，把你列出的参数逐个拆开到可运行层面 来讲。

重点不只是"它是干嘛的"，而是 它在什么状态下生效、和谁一起生效、调错了会发生什么。

一、`osd_memory_target = 939524096`（≈ 896 MiB）

1️⃣ 这个参数真正控制的是什么

这是 OSD 进程的"内存目标值" ，不是硬上限，而是一个 动态调节的参考线：

OSD 内部有多种内存使用者：
- BlueStore cache
- mempool（PG、object、op、log 等）
- RocksDB（DB/WAL）
Ceph 会以 osd_memory_target 为基准：
- 超过目标 → 主动回收缓存
- 远低于目标 → 放宽缓存使用

👉 这是一个 "软控制器"，而不是 cgroup 那种硬限额。

2️⃣ 为什么说它是"最重要的 OSD 参数之一"

因为它 直接决定了 OSD 的整体行为风格：

设得太小
- OSD 经常主动 trim cache
- 性能抖动、IOPS 下降
- HDD 场景尤为明显
设得太大
- 多 OSD 节点容易内存竞争
- page cache + bluestore cache + rocksdb cache 叠加
- 容易被系统 OOM killer 干掉（最危险）

3️⃣ 一个关键误区（非常常见）

❌ 以为这是 "OSD 内存上限"

✅ 实际是 "希望 OSD 大致用到的内存规模"

真正的 OOM 风险来自：

这个值
bluestore_cache_size_*
bluefs_buffered_io
RocksDB 参数
共同叠加后的总效果

二、`osd_max_backfills = 4`

1️⃣ backfill 是什么（必须先分清）

recovery：把缺失副本补回来（数据安全）
backfill：把 PG 挪到新的 OSD 上（CRUSH 变化、扩容、rebalance）

👉 backfill 是"位置迁移"，不是"丢了才补"

2️⃣ 这个参数限制什么

限制：一个 OSD 同时参与的 backfill PG 数量
每个 backfill：
- 消耗磁盘 IO
- 占用网络带宽
- 产生大量后台读写

3️⃣ 为何设为 4 是一个"偏激进但可控"的值

1--2：非常保守，业务稳定但 rebalance 慢
4：常见生产上限
>4：只建议在 业务低谷或专用恢复窗口

如果你同时：

HDD OSD
业务 IO 高峰
backfill 数量高

👉 很容易出现 99% 延迟暴涨

三、`osd_recovery_max_active = 1`

1️⃣ 它和 backfill 的关系

recovery：修复丢失副本（数据安全优先）
backfill：PG 重排（性能与均衡）

这个参数只限制 recovery，不限制 backfill。

2️⃣ 设为 1 的含义（非常保守）

每个 OSD 一次只做一个 recovery
极大地减少：
- 后台读写竞争
- 前台 IO 被饿死

👉 这是典型"业务优先、恢复慢一点也没关系"的配置。

3️⃣ 什么时候这个值会成为问题

多个 OSD 同时 down
副本数较多
磁盘故障频发

👉 恢复窗口可能被拉得很长

👉 长时间处于 degraded 状态

四、`osd_scrub_during_recovery = True`

1️⃣ scrub 是什么（不是 recovery）

scrub：定期校验 PG 中对象是否一致
deep scrub：还会做数据校验（如果你没关 csum）

👉 scrub 是 健康检查，不是修复缺失。

2️⃣ 这个参数允许什么

True：在 recovery/backfill 期间，scrub 也可以运行
False：恢复期间，scrub 暂停

3️⃣ 开启的好处与风险

好处

不会因为频繁恢复而：
- 长时间不 scrub
- 积累 silent corruption 风险

风险

recovery + scrub 都是 重 IO 操作
HDD 场景下可能：
- 恢复变慢
- 业务 IO 抖动

4️⃣ 结合你前面的配置看（关键）

你已经：

osd_recovery_max_active = 1（很保守）
osd_max_backfills = 4（中等偏高）

👉 允许 scrub 并行是可以接受的，但前提是：

scrub 数量（osd_max_scrubs）也被控制住
监控延迟和队列深度

五、`osd_op_queue = wpq`

1️⃣ OSD 的请求不是"来一个处理一个"

OSD 内部所有操作都会进入 操作队列，包括：

客户端读写
recovery
backfill
scrub
peering、PG 维护

👉 调度策略决定了谁先被服务

2️⃣ WPQ（Weighted Priority Queue）怎么工作

按 操作类型 分优先级
客户端 IO 权重大
recovery / backfill 权重低
队列会根据负载动态调度

通俗一点说：

前台业务 IO 插队的权利更大

3️⃣ 为什么 WPQ 是生产推荐

相比 FIFO：
- 不容易被后台任务"淹没"
相比严格优先级：
- 不会让恢复永远没机会执行

👉 WPQ 是 性能与恢复之间的折中算法

六、RBD 相关参数

1️⃣ `rbd_cache = False`

这是哪一层的缓存

这是 RBD 客户端自己的缓存 ，不是前面讲的 client_oc_*。

两者区别：

client_oc_*：librados 对象缓存
rbd_cache：块设备语义层的读写缓存

关闭的影响

优点
- 行为更接近"直接块设备"
- 数据更快到 OSD
- 崩溃一致性更容易理解
缺点
- 小随机写性能下降明显
- 顺序写放大更多落到 OSD

为什么很多生产环境关它

数据库、虚拟机、文件系统：
- 已经自己做缓存（page cache、buffer pool）
多层缓存反而：
- 难以调优
- 崩溃路径复杂

2️⃣ `rbd_read_from_replica_policy = localize`

RBD 默认读哪

默认：从主副本（primary OSD）读

`localize` 做了什么

如果本地节点上有副本：
- 优先从本地 OSD 读
如果没有：
- 再跨节点读

真实收益

减少跨机架/跨节点网络延迟
提升：
- 随机读延迟
- VM / 容器 IO 稳定性

风险与前提

前提：CRUSH 拓扑合理
风险：极端情况下负载不均衡（热点副本）

七、`debug_osd = 0/0`（以及所有 `debug_*`）

1️⃣ `X/Y` 是什么

X：日志级别
Y：日志子系统掩码

0/0 = 完全关闭调试输出

2️⃣ 为什么生产环境必须是 0/0

debug 日志：
- 极度频繁
- 严重影响 IO 性能
OSD 上：
- debug_osd > 1 很容易把磁盘写爆

3️⃣ 正确的使用方式（非常重要）

只在短时间、定向排障时打开
只对单个模块、单个节点打开
排障完立即关闭

八、把这组参数放在一起的"整体画像"

你这套配置体现的是非常明确的策略：

业务 IO 优先，恢复/回填受控，内存使用可调但不激进，RBD 行为偏保守，调试全面关闭。

这是一个 典型的"偏稳态生产环境"取向配置。

如果你愿意，下一步我可以继续帮你做三件更高价值的事（任选）：

把你现在的 OSD / 磁盘 / 内存规模代入，判断这些值是否"过大/过小"
给你一套"故障场景下的临时调参策略"（磁盘坏了 / 扩容 / rebalance）
把 OSD 请求调度（wpq）和 recovery/backfill 的真实执行流程画成一张图

你直接选一个编号即可。

下面按你提供的配置清单，逐条解释每一个参数的含义、作用点（影响哪个组件/路径）、以及常见的调优取向。说明：这些参数来自 Ceph 集群配置（含 BlueStore/BlueFS、MON、OSD、MDS、MSGR、RBD、RocksDB、调试等）。不同 Ceph 版本对默认值/细节可能略有差异，但参数"控制面/数据面"的方向性含义一致。

一、存储引擎与缓存（BlueStore / BlueFS / RocksDB）

1) `bluefs_buffered_io = True`

作用：控制 BlueFS（BlueStore 内部用于管理 RocksDB/WAL 等元数据文件的"文件系统层"）是否使用缓冲 I/O（通过页缓存）。
影响：元数据读写延迟与内存占用、在某些负载下的吞吐稳定性。
常见取向：
- True：更依赖页缓存，可能提升读性能，但内存占用更不确定。
- False：更偏向直接 I/O，减少页缓存干扰，但可能需要更谨慎的 RocksDB/BlueFS 参数配合。

2) `bluestore_cache_size_hdd = 838860800`

作用：为 HDD OSD 指定 BlueStore 缓存目标大小（字节）。
影响：对象数据/元数据缓存命中率、读延迟、OSD 内存占用。
解读：838,860,800 ≈ 800 MiB。
常见取向 ：HDD 通常更依赖缓存来提升随机读；但需与 osd_memory_target 等整体内存策略匹配。

3) `bluestore_cache_size_ssd = 838860800`

作用：为 SSD OSD 指定 BlueStore 缓存目标大小（字节）。
影响：同上，但 SSD 本身延迟更低，缓存收益相对 HDD 小一些；更多是平滑抖动与减少写放大相关的读。
解读：约 800 MiB。

4) `bluestore_cache_trim_max_skip_pinned = 256`

作用：缓存回收（trim）时，最多允许跳过（skip）多少个被"pin"的缓存项再继续尝试回收。
影响：内存紧张时缓存回收的效率与停顿风险。
取向：值越大，回收过程可能更"执着"地寻找可回收对象；太小可能导致回收效率差。

5) `bluestore_csum_type = none`

作用：BlueStore 对对象数据块的校验类型（checksum）。
影响：数据完整性校验能力 vs CPU 开销与写放大。
解读：none 表示不做数据校验（风险更高，但性能/CPU更好）。
建议：生产环境通常更倾向开启校验（取决于硬件可靠性与业务容忍度），但这属于架构层取舍。

6) `bluestore_max_blob_size_hdd = 524288`

作用：HDD 场景下 BlueStore "blob"（数据聚合单元）的最大大小（字节）。
影响：写放大、碎片化、对象覆盖写的效率。
解读：524,288 = 512 KiB。

7) `bluestore_min_alloc_size_hdd = 4096`

作用：HDD 下最小分配单元（allocation size，字节）。
影响：空间利用率与 I/O 对齐效率。
解读：4096 = 4 KiB，常见页/扇区对齐粒度。

8) `bluestore_prefer_deferred_size_hdd = 2048`

作用：HDD 下倾向使用"deferred（延后）写入/分配"策略的阈值（字节）。
影响：小写聚合、写放大与延迟之间的平衡。
解读：2048 = 2 KiB。

9) `bluestore_rocksdb_cf = False`

作用：是否为 RocksDB 使用多个 Column Family（列族）布局。
影响：元数据在 RocksDB 内部组织方式、压实（compaction）行为、性能隔离性。
取向：False 表示更简单的布局；True 可能带来更细粒度调优空间，但复杂度更高。

10) `bluestore_rocksdb_options = ...`

这是给 RocksDB 的一串 options（用逗号分隔）。逐项解释如下（按你提供的键值）：

hik_compaction_delay_ms=600：压实延迟/节流相关的内部参数（多见于定制/厂商化分支命名）。影响写放大与前台抖动。
num_levels=7：LSM-tree 层级数。层级多通常有利于读取与空间放大平衡，但压实复杂度提高。
compression=kNoCompression：不压缩。减少 CPU、提升写入吞吐，但占用更多磁盘。
max_write_buffer_number=64：最多写缓冲（memtable）数量。越大越能吸收写突发，但占内存、也影响 flush/compaction 行为。
min_write_buffer_number_to_merge=32：触发 merge/flush 的阈值（与 memtable 管理相关）。大值更偏向批量化。
recycle_log_file_num=64：可回收复用的日志文件数量，减少频繁创建删除。
write_buffer_size=4194304：单个 memtable 大小（字节）。4,194,304=4 MiB。
target_file_size_base=67108864：L1/L2 等层的基础 SST 文件大小（字节）。67,108,864=64 MiB。
writable_file_max_buffer_size=0：文件写缓冲上限（0 常表示禁用或用默认策略，取决于实现）。
compaction_readahead_size=2097152：压实时预读大小（字节）。2 MiB，提升顺序读效率。
level0_file_num_compaction_trigger=16：L0 文件数达到该值触发 compaction。
level0_slowdown_writes_trigger=128：L0 文件数达到该值开始"减速写入"（节流）。
level0_stop_writes_trigger=256：L0 文件数达到该值停止写入（强背压，避免失控）。
bytes_per_sync=4194304：每写入这么多字节调用一次 sync（影响写入持久化节奏）。
wal_bytes_per_sync=1048576：WAL 每写入这么多字节 sync 一次。
optimize_filters_for_hits=1：优化过滤器以提高命中读性能（布隆过滤器等）。
bloom_locality=1：布隆过滤器 locality 优化参数（更偏向 cache 友好）。
skip_stats_update_on_db_open=true：DB 打开时跳过部分统计更新，加快启动/打开速度。
max_subcompactions=1：并行子压实数量。1 表示压实并行度低，减少资源竞争但压实速度慢。
max_bytes_for_level_base=4831838208：某层（通常 L1）的基准容量（字节），决定各层大小与 compaction 频率。
compaction_pri=kMinOverlappingRatio：压实优先级策略（优先压实重叠比例小/大取决于策略定义），影响写放大与读放大。
max_total_wal_size=1073741824：WAL 总大小上限（字节）。1 GiB，超过则触发 flush 等行为。

总体含义：这套 RocksDB 参数偏向"吸收写突发 + 减少压缩 CPU + 用阈值控制 L0 背压"，但会用更多磁盘与内存。

11) `bluestore_shard_finishers = True`

作用：将 finisher（异步回调/完成队列）进行分片（shard）。
影响：OSD 异步任务完成路径的并行度与延迟抖动。
取向：True 通常有利于多核扩展，降低单队列竞争。

12) `rocksdb_block_size = 4096`

作用：RocksDB 数据块（block）大小。
影响：读取放大、缓存利用率、随机读性能。
解读：4KiB 常与页大小一致，偏向小粒度随机读。

13) `rocksdb_cache_shard_bits = 1`

作用：RocksDB block cache 分片数量的指数位数（2^bits）。
影响：并发访问 cache 的锁竞争与内存碎片。
解读：1 表示 2 个 shard。

二、客户端与对象缓存（Client / ObjectCacher / Objecter）

14) `client_die_on_failed_remount = False`

作用：客户端 remount 失败时是否直接退出。
影响：客户端在故障场景下的可用性与可观测性。
取向：False 更"韧性"，但也可能掩盖问题；True 更激进，利于快速失败。

15) `client_dirsize_rbytes = False`

作用：目录大小统计是否使用 rbytes（递归字节数）等更精确/更昂贵的统计方式（具体语义与 CephFS 实现相关）。
影响：CephFS 目录统计准确性 vs 性能开销。

16) `client_oc_max_dirty = 41943040`

作用：客户端 ObjectCacher 最大脏数据（dirty）字节数上限。
解读：约 40 MiB。
影响：写缓存大小、回写压力、客户端内存占用与写延迟。

17) `client_oc_max_dirty_age = 2`

作用：脏数据允许滞留的最大时间（秒）后更积极回写。
影响：写延迟（更低）与吞吐批量化（更高）之间权衡。

18) `client_oc_max_objects = 60`

作用：ObjectCacher 缓存对象数量上限。
影响：元数据/对象缓存命中率与内存占用。

19) `client_oc_size = 104857600`

作用：ObjectCacher 总缓存大小（字节）。
解读：100 MiB。
影响：读缓存命中率与内存占用。

20) `client_oc_target_dirty = 4194304`

作用：期望脏数据目标值（字节），超过该值会更积极回写。
解读：4 MiB。
影响：回写节奏与突发写吸收能力。

21) `client_reconnect_stale = True`

作用：允许客户端对"可能过期/陈旧"的会话或连接进行重连处理（更多是故障恢复行为控制）。
影响：故障期间恢复速度与一致性风险的权衡（通常是更偏向可用性）。

22) `objecter_inflight_op_bytes = 524288000`

作用：对象层（objecter）允许在途（in-flight）操作的总字节数上限。
解读：约 500 MiB。
影响：客户端/OSD 的并发深度、吞吐与内存压力。

23) `objecter_inflight_ops = 5120`

作用：objecter 允许的在途操作数量上限。
影响：并发度与尾延迟；过大可能在拥塞时放大抖动。

三、网络与消息层（msgr / cluster 网络）

24) `cluster_network = 172.16.111.0/24`

作用：集群内部复制/心跳/恢复等后台流量的网络网段。
影响：数据面隔离（与 public_network 分离可降低干扰）。

25) `public_network = 172.16.111.0/24`

作用：客户端访问与对外服务网络网段。
解读：此处与 cluster_network 相同，表示未做网络隔离。

26) `ipversion = ipv4`

作用：指定使用 IPv4。
影响：绑定与监听地址族。

27) `ms_async_op_threads = 16`

作用：异步 messenger 的操作线程数。
影响：网络处理并发度、CPU 占用与延迟。

28) `ms_async_set_affinity = False`

作用：是否给异步 messenger 线程设置 CPU 亲和性。
影响：在 NUMA/多核下的稳定性；开启可提升一致性但降低调度弹性。

29) `ms_bind_ipv4 = True`

作用：允许绑定 IPv4。
影响：监听行为。

30) `ms_bind_ipv6 = False`

作用：禁用 IPv6 绑定。
影响：纯 IPv4 环境更简单。

31) `ms_dispatch_throttle_bytes = 419430400`

作用：消息分发（dispatch）层的流量节流阈值（字节）。
解读：约 400 MiB。
影响：避免瞬时消息洪峰导致内存暴涨，但可能限制峰值吞吐。

32) `ms_max_backoff = 2`

作用：网络重试/退避最大值（秒或某个单位，具体取决实现）。
影响：拥塞/丢包场景下的重连与发送节奏。

四、MON（监视器）集群与一致性（Paxos / health / 配额）

33) `mon_host = 172.16.111.11:6789,172.16.111.12:6789,172.16.111.13:6789`

作用：MON 节点列表与端口。
影响：客户端与守护进程发现 MON 的入口信息。

34) `mon_initial_members = node1,node2,node3`

作用：初始化 MON 仲裁成员名列表。
影响：monmap 初始形成。

35) `mon_allow_pool_delete = True`

作用：是否允许删除 pool。
影响：安全性与误操作风险。True 风险更高但管理更方便。

36) `mon_allow_pool_size_one = True`

作用：是否允许副本数 size=1 的 pool。
影响：数据可靠性（size=1 没有冗余）vs 资源节省。

37) `mon_client_hunt_interval = 2`

作用：客户端"hunt"（寻找可用 MON、重试连接）的基本间隔。
影响：故障切换速度与连接风暴风险。

38) `mon_client_hunt_interval_backoff = 1`

作用：hunt 的退避系数/步进控制。
影响：重试节奏。

39) `mon_client_hunt_interval_max_multiple = 5`

作用：hunt 间隔最大可放大倍数。
影响：避免长期故障时过于频繁重试。

40) `mon_client_hunt_interval_min_multiple = 1`

作用：hunt 间隔最小倍数。
影响：最低重试频率控制。

41) `mon_client_hunt_parallel = 5`

作用：并行 hunt 的数量（并发探测多个 MON）。
影响：恢复速度与连接开销。

42) `mon_client_ping_interval = 2`

作用：客户端 ping MON 的间隔（秒）。
影响：故障检测速度与额外网络开销。

43) `mon_client_ping_timeout = 7`

作用：客户端 ping 超时（秒）。
影响：判定 MON 不可达的速度。

44) `mon_clock_drift_allowed = 60`

作用：允许的时钟漂移阈值（秒）。
影响：时钟不同步导致的健康告警与选主稳定性。

45) `mon_clock_drift_warn_backoff = 60`

作用：时钟漂移告警的退避/抑制周期（秒）。
影响：告警频率。

46) `mon_compact_on_trim = False`

作用：MON 数据库在 trim（裁剪旧记录）时是否触发 compact（压缩整理）。
影响：磁盘空间回收速度 vs 当下 CPU/IO 开销。

47) `mon_data_avail_warn = 15`

作用：MON 数据分区可用空间低于某阈值（通常百分比）触发告警。
影响：容量告警敏感度。

48) `mon_election_timeout = 5`

作用：MON 选举超时（秒）。
影响：选举收敛速度与误判风险（网络抖动时过小会频繁选举）。

49) `mon_health_data_update_interval = 20`

作用：MON 更新 health 相关数据的间隔（秒）。
影响：健康状态刷新频率。

50) `mon_lease = 3`

作用：Paxos lease（租约）时长（秒）。
影响：一致性/性能/故障切换速度。

51) `mon_lease_ack_timeout_factor = 2`

作用：lease ack 超时因子，用于推导超时阈值。
影响：在延迟波动时是否更容易触发超时。

52) `mon_max_pg_per_osd = 1024000`

作用：MON 允许的每 OSD 最大 PG 数上限（用于保护配置异常）。
影响：防止 PG 配置错误导致 MON/OSD 被压垮。

53) `mon_osd_adjust_down_out_interval = False`

作用：是否让 MON 自动调整 down/out 的超时策略（动态化）。
影响：自适应 vs 可预测性。

54) `mon_osd_adjust_heartbeat_grace = False`

作用：是否自动调整 OSD 心跳宽限（grace）。
影响：同上。

55) `mon_osd_auto_mark_in = True`

作用：OSD 恢复后是否自动 mark in。
影响：自动化恢复速度 vs 运维控制（某些场景希望手工确认再 in）。

56) `mon_osd_backfillfull_ratio = 0.93`

作用：达到该使用率时进入 backfillfull 状态（限制 backfill）。
影响：避免 backfill 导致磁盘进一步逼近 full。

57) `mon_osd_destroyed_out_interval = 94608000`

作用：OSD 被认为 destroyed 后，自动 out 的间隔（秒级）。
解读：94,608,000 秒约等于 3 年。
影响：极端场景的自动清理节奏（非常保守）。

58) `mon_osd_down_out_interval = 2000`

作用：OSD down 多久后自动标记 out（秒）。
解读：约 33 分 20 秒。
影响：故障恢复/重平衡触发速度；过短会误伤短暂抖动，过长会延迟恢复。

59) `mon_osd_full_ratio = 0.97`

作用：达到该使用率进入 full 状态（强限制写入）。
影响：保护磁盘不被写爆。

60) `mon_osd_min_down_reporters = 2`

作用：至少需要多少个报告者（reporter）报告某 OSD down，MON 才认定 down。
影响：减少单点误报带来的抖动。

61) `mon_osd_min_in_ratio = 0.3`

作用：集群至少有多少比例 OSD 处于 in 才允许某些操作/状态转换（保护性阈值）。
影响：在大面积故障时避免雪崩式重平衡。

62) `mon_osd_nearfull_ratio = 0.9`

作用：达到该使用率进入 nearfull 预警/限制阶段。
影响：提前告警与渐进限流。

63) `mon_osd_pool_ec_fast_read = True`

作用：纠删码（EC）pool 的 fast read 优化策略开关（尽量从更少的 shard/更快路径读取）。
影响：EC 读性能与资源使用。

64) `mon_osd_report_timeout = 25`

作用：OSD 状态报告超时阈值（秒）。
影响：MON 对 OSD "失联"的判定敏感度。

65) `mon_osd_reporter_subtree_level = rack`

作用：OSD down 报告者的拓扑子树级别（CRUSH 层级），用于故障判定/仲裁。
影响：跨机架/同机架故障判断的鲁棒性。

66) `mon_sync_max_payload_size = 10485760`

作用：MON 同步（sync）单次最大负载大小（字节）。
解读：10 MiB。
影响：同步效率与单次消息内存占用。

67) `mon_sync_timeout = 300`

作用：MON 同步超时（秒）。
影响：同步失败判定与重试。

68) `mon_tick_interval = 2`

作用：MON 主循环 tick 间隔（秒）。
影响：内部定时任务/超时检查的粒度。

69) `mon_warn_pg_not_deep_scrubbed_ratio = 0`

作用：PG 长期未 deep-scrub 的告警比例阈值（0 通常表示禁用或极端敏感，需结合实现理解；很多场景 0 表示"不告警"）。
影响：健康告警策略。

70) `mon_warn_pg_not_scrubbed_ratio = 0`

作用：PG 长期未 scrub 的告警比例阈值（同上）。
影响：健康告警策略。

71) `paxos_stash_full_interval = 10`

作用：Paxos stash（缓存/暂存）满相关的处理周期（秒或 tick 单位，依实现）。
影响：MON 一致性日志管理行为与性能。

五、OSD：内存、心跳、恢复、scrub、队列与 PG 统计

72) `osd_allocator_update_disable = True`

作用：是否禁用分配器（allocator）某些更新行为（常用于减少运行期开销或配合特定 bug/workaround）。
影响：空间分配元数据更新频率与性能/一致性风险权衡（需谨慎）。

73) `osd_beacon_report_interval = 6`

作用：OSD 向 MON 报告 beacon 的间隔（秒）。
影响：OSD 存活检测与网络开销。

74) `osd_client_message_cap = 1000000`

作用：OSD 允许累积的客户端消息数量上限（cap）。
影响：保护 OSD 内存，避免消息堆积失控；过小可能限制高并发吞吐。

75) `osd_client_message_size_cap = 4194304000`

作用：OSD 允许累积的客户端消息总字节上限。
解读：约 3.9 GiB。
影响：同上，更偏向字节维度保护。

76) `osd_client_watch_timeout = 20`

作用：客户端 watch/notify 相关机制的超时（秒）。
影响：watch 会话保活与故障检测速度（尤其对 RADOS watch 用户）。

77) `osd_crush_update_on_start = False`

作用：OSD 启动时是否自动更新 CRUSH 信息。
影响：自动化 vs 控制；关闭可避免启动时对 CRUSH 的意外修改。

78) `osd_failsafe_full_ratio = 0.99`

作用：终极保护阈值，达到时进入 failsafe full（非常严格限制写入）。
影响：防止磁盘写满导致更严重故障。

79) `osd_force_recovery_pg_log_entries_factor = 1`

作用：恢复时与 PG 日志条目相关的强制恢复因子。
影响：恢复优先级与日志处理策略（更偏保守/默认）。

80) `osd_heartbeat_grace = 20`

作用：OSD 心跳宽限期（秒），超过未收到心跳则判定对端异常。
影响：故障检测速度 vs 网络抖动误判。

81) `osd_heartbeat_interval = 6`

作用：OSD 心跳发送间隔（秒）。
影响：检测粒度与网络开销。

82) `osd_max_backfills = 4`

作用：每个 OSD 允许的并行 backfill 数量。
影响：数据重平衡速度 vs 前台 I/O 影响（backfill 越多，恢复越快但越"吵"）。

83) `osd_max_pg_log_entries = 3000`

作用：PG 日志最大条目数上限（超过会触发裁剪/回收等机制）。
影响：恢复能力、日志占用与性能。

84) `osd_max_scrubs = 2`

作用：并行 scrub 的上限数量。
影响：一致性校验速度 vs 前台性能影响。

85) `osd_max_write_size = 256`

作用：单次写操作最大 size（通常单位为 MiB 或对象块相关单位，取决实现/上下文；在 Ceph 中常见为 MB 级别的限制项）。
影响：大写请求的切分、内存与网络峰值。

86) `osd_memory_target = 939524096`

作用：OSD 目标内存占用（字节），用于 BlueStore/OSD 自适应内存管理。
解读：约 896 MiB。
影响：缓存、队列、元数据等的总体内存预算。

87) `osd_min_pg_log_entries = 100`

作用：PG 日志最小条目目标（低于该值不会继续裁剪）。
影响：恢复所需历史信息保留。

88) `osd_mon_heartbeat_interval = 3`

作用：OSD 向 MON 的心跳/联络间隔（秒）。
影响：MON 侧对 OSD 存活判断速度。

89) `osd_mon_report_interval_max = 20`

作用：OSD 向 MON 状态报告的最大间隔（秒）。
影响：状态刷新频率上限。

90) `osd_op_complaint_time = 10`

作用：操作（op）超过该时长（秒）可能被视为"慢请求"并触发告警/日志。
影响：慢请求告警敏感度。

91) `osd_op_num_threads_per_shard_hdd = 1`

作用：HDD OSD 每个 shard 的 op 线程数。
影响：并发处理能力与磁盘寻道压力；HDD 通常不宜过多线程以免抖动。

92) `osd_op_queue = wpq`

作用：OSD 操作队列类型（wpq 常指 WeightedPriorityQueue 等实现）。
影响：前台/后台请求调度公平性与延迟。

93) `osd_op_queue_cut_off = low`

作用：队列 cut-off 等级，用于区分/截断不同优先级请求（例如把低优先级归类或限制）。
影响：在拥塞时优先保障高优先级（客户端前台）请求。

94) `osd_pg_log_dups_tracked = 100`

作用：跟踪 PG 日志重复项（dups）的数量上限，用于异常/一致性处理。
影响：内存与日志一致性处理能力。

95) `osd_pg_stat_report_interval_max = 20`

作用：PG 统计信息向 MON 报告的最大间隔（秒）。
影响：MON 侧 PG 状态刷新频率。

96) `osd_pool_default_crush_rule = -1`

作用：默认 pool 使用的 CRUSH rule（-1 通常表示使用系统默认/按类型自动选择）。
影响：数据放置策略。

97) `osd_pool_default_pg_autoscale_mode = off`

作用：默认 PG autoscale 模式关闭。
影响：PG 数量不会自动按容量/负载调整；需要人工规划（更可控但运维负担更大）。

98) `osd_recovery_max_active = 1`

作用：每个 OSD 允许的并行 recovery active 数量。
影响：恢复速度 vs 前台性能影响（值小更保守、前台更稳但恢复慢）。

99) `osd_recovery_max_single_start = 1`

作用：单次启动的 recovery 数量限制（与恢复调度相关）。
影响：恢复并发的爬升速度与抖动。

100) `osd_recovery_op_priority = 1`

作用：恢复操作在队列中的优先级。
影响：恢复与前台 I/O 的竞争关系（数字越大/越小哪个更高取决实现的优先级定义，但总之是"恢复排队优先级"）。

101) `osd_recovery_priority = 1`

作用：恢复任务整体优先级（宏观调度）。
影响：同上。

102) `osd_recovery_sleep = 0.4`

作用：恢复过程 sleep（秒），用于节流恢复 I/O。
影响：恢复对前台的影响（sleep 越大越温和，但恢复更慢）。

103) `osd_scrub_chunk_max = 25`

作用：scrub 单次处理 chunk 的最大值（对象数或某单位，视实现）。
影响：scrub 批量大小与对前台影响。

104) `osd_scrub_chunk_min = 5`

作用：scrub 单次处理 chunk 的最小值。
影响：scrub 任务粒度。

105) `osd_scrub_during_recovery = True`

作用：恢复期间是否允许 scrub。
影响：数据一致性校验与恢复争抢资源；True 可能增加负载，但保证校验不长期延期。

106) `osd_scrub_sleep = 0.01`

作用：scrub 节流 sleep（秒）。
影响：scrub 对前台 I/O 的扰动。

107) `osd_target_pg_log_entries_per_osd = 300000`

作用：每 OSD 目标 PG 日志条目数（用于日志裁剪/目标控制）。
影响：恢复信息保留量与磁盘占用。

六、MDS（CephFS 元数据服务器）

108) `mds_beacon_grace = 6`

作用：MDS beacon 宽限期（秒），超出可能判定 MDS 不健康。
影响：MDS 故障检测速度与误判。

109) `mds_beacon_interval = 2`

作用：MDS 发送 beacon 的间隔（秒）。
影响：同上。

110) `mds_reconnect_timeout = 2`

作用：MDS 相关重连超时（秒）。
影响：客户端/会话恢复速度。

111) `mds_session_blacklist_on_timeout = False`

作用：会话超时时是否直接 blacklist 客户端。
影响：安全性/一致性 vs 可用性；关闭 blacklist 更宽容，但可能延长异常会话影响。

112) `mds_tick_interval = 2`

作用：MDS 主循环 tick 间隔（秒）。
影响：内部定时任务粒度。

七、管理器（MGR）

113) `mgr_disabled_modules = diskprediction_local`

作用：禁用指定的 MGR 模块（这里是本地磁盘预测模块）。
影响：减少不需要的功能与资源占用。

114) `mgr_stats_threshold = 0`

作用：MGR 统计阈值（用于触发/过滤某些统计采集或告警，语义依实现）。
取向：0 常表示禁用阈值过滤或用默认路径（需结合版本）。

八、RBD（块存储）

115) `rbd_cache = False`

作用：客户端 RBD 缓存开关（通常指 librbd 客户端写回缓存）。
影响：性能 vs 崩溃一致性语义。关闭缓存更安全、更可预测，但可能牺牲性能。

116) `rbd_concurrent_management_ops = 50`

作用：并发管理操作上限（如创建、删除、快照等管理类操作）。
影响：大规模运维操作吞吐与集群压力。

117) `rbd_read_from_replica_policy = localize`

作用：从副本读（read-from-replica）的策略：偏向"本地化"（尽量从本地/近端副本读）。
影响：读延迟与跨网络流量。

118) `rbd_read_from_replica_policy_location = hci_default`

作用：与 localize 策略配套的位置标签/拓扑位置名（用于判定"本地/近端"的范围）。
影响：副本读的选择范围。

119) `rbd_remove_sleep_ms = 0`

作用：RBD remove（删除）流程中的 sleep（毫秒）节流。
影响：删除对集群压力的平滑；0 表示不额外 sleep。

120) `rbd_snap_rollback_sleep_ms = 0`

作用：快照回滚过程中的 sleep（毫秒）节流。
影响：回滚对前台的影响；0 表示不节流。

九、调试与日志开关（debug_*、mempool_debug、fsid 等）

121) `fsid = ed347113-e8bd-4e55-865c-ef663c516a5a`

作用：集群唯一 ID。
影响：标识集群；客户端与守护进程用于确认连接到正确的集群。

122) `mempool_debug = True`

作用：启用内存池（mempool）调试。
影响：更强的内存使用可观测性与检测能力，但可能增加开销与日志量。

123) `debug_asok = 0/0`

124) `debug_auth = 0/0`

125) `debug_bdev = 0/0`

126) `debug_bluefs = 0/0`

127) `debug_bluestore = 0/0`

128) `debug_civetweb = 0/0`

129) `debug_compressor = 0/0`

130) `debug_crush = 0/0`

131) `debug_crypto = 0/0`

132) `debug_dpdk = 0/0`

133) `debug_eventtrace = 0/0`

134) `debug_filestore = 0/0`

135) `debug_finisher = 0/0`

136) `debug_fuse = 0/0`

137) `debug_heartbeatmap = 0/0`

138) `debug_javaclient = 0/0`

139) `debug_journal = 0/0`

140) `debug_kinetic = 0/0`

141) `debug_kstore = 0/0`

142) `debug_leveldb = 0/0`

143) `debug_mds = 0/0`

144) `debug_mds_balancer = 0/0`

145) `debug_mds_locker = 0/0`

146) `debug_mds_log = 0/0`

147) `debug_mds_log_expire = 0/0`

148) `debug_mds_migrator = 0/0`

149) `debug_memdb = 0/0`

150) `debug_mgr = 0/0`

151) `debug_mgrc = 0/0`

152) `debug_mon = 0/0`

153) `debug_osd = 0/0`

154) `debug_paxos = 0/0`

155) `debug_perfcounter = 0/0`

156) `debug_rgw = 0/0`

157) `debug_rocksdb = 0/0`

158) `debug_throttle = 0/0`

159) `debug_xio = 0/0`

共同作用 ：分别控制对应子系统的日志/调试级别（通常格式为 subsys = <log>/<gather> 或类似含义，取决版本；两个数字常对应不同输出通道/不同详细度）。
影响：诊断能力 vs 性能与日志量。
解读：0/0 一般表示关闭调试输出（最少日志）。

十、你这份配置的"整体画像"（便于理解各参数组合意图）

从这些值的组合可以看出，你的配置整体偏向：

保守恢复 ：osd_recovery_max_active=1、osd_recovery_sleep=0.4，减轻恢复对前台影响，但恢复会更慢。
较强写突发吸收（元数据侧） ：RocksDB max_write_buffer_number=64、较多 L0 阈值等，倾向吞吐与稳定背压。
关闭数据校验 ：bluestore_csum_type=none，性能优先但数据端到端校验能力弱。
网络不隔离 ：public_network 与 cluster_network 相同，管理简单但业务与后台流量互相干扰风险更高。
PG 自动扩缩关闭 ：osd_pool_default_pg_autoscale_mode=off，需要人工规划 PG。

如果你希望我进一步"对照你的业务目标"给出调优建议（例如：你更在意前台延迟、还是更在意故障恢复时间、是否是 HDD/SSD 混部、每台 OSD 内存多少、是否跑 CephFS/RBD/RGW），你可以直接说目标与硬件概况；在不改动你现有架构前提下，我可以把上述参数按"必须改/建议改/保持不动"分级，并给出风险说明与验证方法。

一、认证 / 客户端通用参数

auth_client_required = none

auth_cluster_required = none

auth_service_required = none

二、BlueStore / BlueFS（OSD 存储引擎）

bluefs_buffered_io = True

bluestore_cache_size_hdd = 838860800

bluestore_cache_size_ssd = 838860800

bluestore_cache_trim_max_skip_pinned = 256

bluestore_csum_type = none

bluestore_max_blob_size_hdd = 524288

bluestore_min_alloc_size_hdd = 4096

bluestore_prefer_deferred_size_hdd = 2048

bluestore_rocksdb_cf = False

bluestore_rocksdb_options = ...

bluestore_shard_finishers = True

三、客户端缓存（Object Cache）

client_oc_size = 104857600

client_oc_max_dirty = 41943040

client_oc_target_dirty = 4194304

client_oc_max_dirty_age = 2

client_oc_max_objects = 60

client_reconnect_stale = True

四、网络配置

public_network = 172.16.111.0/24

cluster_network = 172.16.111.0/24

ipversion = ipv4

五、Monitor（MON）参数

mon_host = 172.16.111.11:6789,...

mon_initial_members = node1,node2,node3

mon_allow_pool_delete = True

mon_osd_full_ratio = 0.97

mon_osd_nearfull_ratio = 0.9

六、OSD 核心参数

osd_memory_target = 939524096

osd_max_backfills = 4

osd_recovery_max_active = 1

osd_scrub_during_recovery = True

osd_op_queue = wpq

七、RBD（块存储）

rbd_cache = False

rbd_read_from_replica_policy = localize

八、调试参数（debug_*）

debug_osd = 0/0（以及所有 debug_*）

总体理解一句话总结

1) bluefs_buffered_io = True

这参数到底控制什么

开 True 的效果（你现在的配置）

潜在副作用

适用建议（经验规律）

2) bluestore_cache_size_hdd = 838860800（约 800 MiB）

它控制的"缓存"是什么

为什么分 HDD / SSD 两套

调大/调小会怎样

关键点

3) bluestore_cache_size_ssd = 838860800（约 800 MiB）

与 HDD 的区别理解

常见取值思路

4) bluestore_cache_trim_max_skip_pinned = 256

"pinned" 是什么（直观解释）

这个参数做什么

调参影响

为什么 256 常见

5) bluestore_csum_type = none

它真正影响什么

好处

风险（这是高风险项）

适用场景

6) bluestore_max_blob_size_hdd = 524288（512 KiB）

blob 是什么

这个参数的含义

调参权衡

7) bluestore_min_alloc_size_hdd = 4096（4 KiB）

它是"最小分配粒度"

影响点

为什么不是更大（例如 64KB）

8) bluestore_prefer_deferred_size_hdd = 2048（2 KiB）

"deferred write" 直观解释

这个参数做什么

`auth_client_required = none`

`auth_cluster_required = none`

`auth_service_required = none`

`bluefs_buffered_io = True`

`bluestore_cache_size_hdd = 838860800`

`bluestore_cache_size_ssd = 838860800`

`bluestore_cache_trim_max_skip_pinned = 256`

`bluestore_csum_type = none`

`bluestore_max_blob_size_hdd = 524288`

`bluestore_min_alloc_size_hdd = 4096`

`bluestore_prefer_deferred_size_hdd = 2048`

`bluestore_rocksdb_cf = False`

`bluestore_rocksdb_options = ...`

`bluestore_shard_finishers = True`

`client_oc_size = 104857600`

`client_oc_max_dirty = 41943040`

`client_oc_target_dirty = 4194304`

`client_oc_max_dirty_age = 2`

`client_oc_max_objects = 60`

`client_reconnect_stale = True`

`public_network = 172.16.111.0/24`

`cluster_network = 172.16.111.0/24`

`ipversion = ipv4`

`mon_host = 172.16.111.11:6789,...`

`mon_initial_members = node1,node2,node3`

`mon_allow_pool_delete = True`

`mon_osd_full_ratio = 0.97`

`mon_osd_nearfull_ratio = 0.9`

`osd_memory_target = 939524096`

`osd_max_backfills = 4`

`osd_recovery_max_active = 1`

`osd_scrub_during_recovery = True`

`osd_op_queue = wpq`

`rbd_cache = False`

`rbd_read_from_replica_policy = localize`

`debug_osd = 0/0`（以及所有 debug_*）

1) `bluefs_buffered_io = True`

开 `True` 的效果（你现在的配置）

2) `bluestore_cache_size_hdd = 838860800`（约 800 MiB）

3) `bluestore_cache_size_ssd = 838860800`（约 800 MiB）

4) `bluestore_cache_trim_max_skip_pinned = 256`

5) `bluestore_csum_type = none`

6) `bluestore_max_blob_size_hdd = 524288`（512 KiB）

7) `bluestore_min_alloc_size_hdd = 4096`（4 KiB）

8) `bluestore_prefer_deferred_size_hdd = 2048`（2 KiB）

9) `bluestore_rocksdb_cf = False`

10) `bluestore_rocksdb_options = ...`（这组最关键也最复杂）

11) `bluestore_shard_finishers = True`

二、`client_oc_size = 104857600`（100MB）

三、`client_oc_max_dirty = 41943040`（40MB）

它和 `client_oc_size` 的关系

四、`client_oc_target_dirty = 4194304`（4MB）

五、`client_oc_max_dirty_age = 2`（秒）

六、`client_oc_max_objects = 60`

七、`client_reconnect_stale = True`

一、`osd_memory_target = 939524096`（≈ 896 MiB）

二、`osd_max_backfills = 4`

三、`osd_recovery_max_active = 1`

四、`osd_scrub_during_recovery = True`

五、`osd_op_queue = wpq`