注意

本文档适用于 Ceph 开发版本。

故障排除 OSDs

在排除集群的OSD之前，检查监控器和网络。

首先，确定监控器是否有仲裁。运行命令或命令，如果Ceph显示，则存在监控器仲裁。ceph health命令或ceph -s命令，如果Ceph显示，则存在监控器仲裁。HEALTH_OK then there is a monitor quorum.

如果监控器没有仲裁或监控器状态存在错误，请在继续之前通过参考中的内容解决监控器问题监控器故障排除.

接下来，检查您的网络以确保它们正常运行。网络可以对OSD操作和性能产生重大影响。查找主机端的丢包和交换机端的CRC错误。

获取有关OSD的数据

在排除OSD时，收集有关OSD的各种信息很有用。一些信息来自OSD监控的实践（例如，通过运行命令）。监控OSD（例如，通过运行命令）。ceph osd tree额外的信息涉及您的集群拓扑，并在以下部分中讨论。

Ceph日志

Ceph日志文件存储在/var/log/ceph下。除非路径已更改（或您处于存储日志在不同位置的容器化环境），否则可以通过运行以下命令列出日志文件：

ls /var/log/ceph

如果日志详细信息不足，请更改日志级别。为确保Ceph在高日志量下表现良好，请参阅日志记录和调试.

管理套接字

使用管理套接字工具检索运行时信息。首先，通过运行以下命令列出Ceph守护程序的套接字：

ls /var/run/ceph

接下来，运行以下形式的命令（将{daemon-name}替换为特定守护程序的名字：例如，osd.0）：

ceph daemon {daemon-name} help

或者，使用指定的命令（“套接字文件”是{socket-file} specified (a “socket file” is a specific file in /var/run/ceph）：

ceph daemon {socket-file} help

中的特定文件）。

  • 在运行时列出Ceph配置

  • 导出历史操作

  • 导出操作优先队列状态

  • 导出正在进行的操作

  • 导出性能计数器

显示空闲空间

文件系统问题可能会出现。要显示您的文件系统的空闲空间，请运行以下命令：

df -h

要查看此命令的支持语法和选项，请运行df --help.

I/O统计

The iostat工具可用于识别I/O相关问题。运行以下命令：

iostat -x

诊断消息

要从内核检索诊断消息，请运行dmesg命令并指定less, more, grep或tail作为输出。例如：

dmesg | grep scsi

无需重新平衡即可停止

有时可能需要对你的集群的子集进行维护或解决影响故障域（例如，机架）的问题。但是，当你因为维护而停止OSD时，你可能希望防止CRUSH自动重新平衡集群。要避免这种重新平衡行为，请通过运行以下命令将集群设置为noout:

ceph osd set noout

警告

这更多的是一种思想练习，旨在让读者了解故障域和CRUSH行为，而不是建议在Luminous之后的世界中运行ceph osd set noout。当OSD返回到up状态时，重新平衡将恢复，并且ceph osd set noout命令引入的变化将被撤销。

然而，在Luminous及以后的版本中，更安全的方法是仅标记受影响的OSD。要向特定OSD添加或删除noout标志，请运行如下命令：

ceph osd add-noout osd.0
ceph osd rm-noout  osd.0

还可以标记整个CRUSH桶。例如，如果你计划为了添加RAM而关闭prod-ceph-data1701，你可以运行以下命令：

ceph osd set-group noout prod-ceph-data1701

设置标志后，停止OSD以及故障域内需要维护的其他Ceph服务：

systemctl stop ceph\*.service ceph\*.target

Note

当OSD停止时，OSD内的任何放置组都将被标记为degraded.

。维护完成后，需要重新启动OSD以及任何已停止的其他守护程序。但是，如果主机作为维护的一部分被重新启动，则不需要重新启动，它们将自动启动。要重新启动OSD或其他守护程序，请使用以下形式的命令：

sudo systemctl start ceph.target

最后，根据需要使用以下命令取消设置noout标志：

ceph osd unset noout
ceph osd unset-group noout prod-ceph-data1701

许多现代Linux发行版使用systemd进行服务管理。然而，对于某些操作系统（尤其是较旧的系统），可能需要发出等效的service或start/stop commands.

OSD未运行

在正常情况下，重新启动ceph-osd守护程序将使其能够重新加入集群并恢复。

如果集群已启动但OSD没有启动，请检查以下内容：

If the cluster has started but an OSD isn’t starting, check the following:

  • 配置文件：如果您无法从新安装中启动OSD，请检查您的配置文件以确保它符合标准（例如，确保它说host而不是hostname，等等）。

  • 检查路径：确保配置中指定的路径对应于实际存在的数据和元数据的路径（例如，期刊、WAL和DB的路径）。将OSD数据与元数据分开，以查看配置文件和实际挂载中是否存在错误。如果是这样，这些错误可能是OSD无法启动的原因。要将元数据存储在单独的块设备上，请分区或LVM驱动器并为每个OSD分配一个分区。

  • 检查最大线程数：如果集群有一个节点上的OSD数量特别多，它可能会达到默认的最大线程数（通常为32,000）。这尤其是在恢复期间更容易发生。将最大线程数增加到最大可能的线程数（4194303）可能有助于解决问题。要增加到最大线程数，请运行以下命令：

    sysctl -w kernel.pid_max=4194303

    如果这个问题得到解决，您必须通过在kernel.pid_max设置来使增加永久化。例如：/etc/sysctl.d下或在主/etc/sysctl.conf文件中包含

    kernel.pid_max = 4194303

  • 检查“nf_conntrack”：这个连接跟踪和连接限制系统导致许多生产Ceph集群出现问题。问题通常缓慢而微妙地出现。随着集群拓扑和客户端工作负载的增长，神秘的和间歇性的连接故障和性能故障越来越多，尤其是在一天中的某些时间。要开始衡量您的问题，请检查syslog的“表已满”事件。解决这类问题的一种方法如下：首先，使用sysctl工具将nf_conntrack_max分配给更高的值。接下来，将nf_conntrack_buckets的值提高到nf_conntrack_buckets× 8 =nf_conntrack_max；这可能需要运行sysctl（例如，"echo 131072 > /sys/module/nf_conntrack/parameters/hashsize）之外的命令。解决这个问题的另一种方法是黑名单相关内核模块，以完全禁用处理。这种方法很强大，但也很脆弱。模块和模块必须列出的顺序在不同的内核版本中可能会有所不同。即使被黑名单，内核模块iptables和docker也可能有时会激活连接跟踪，因此我们建议对可调参数采用“设置并忘记”策略。在现代系统上，这种方法不会消耗大量资源。

  • 内核版本：确定正在使用的内核版本和发行版。默认情况下，Ceph使用可能存在错误或与某些发行版或内核版本冲突的第三方工具（例如，Google的gperftools和TCMalloc）。检查操作系统建议和每个Ceph版本的

  • 段错误：如果存在段错误，请增加日志级别并重新启动有问题的守护程序。如果段错误再次发生，请在Ceph错误跟踪器https://tracker.ceph/com/projects/ceph和dev和ceph-users邮件列表存档https://ceph.io/resources中搜索，看看其他人是否遇到过并报告了这些问题。如果这确实是一个全新且独特的故障，请向dev邮件列表报告并提供以下信息：正在运行的特定Ceph版本，ceph.conf（机密信息XXX被遮盖），您的监控器状态输出，以及您的日志文件中的摘录。

OSD失败

当OSD失败时，这意味着一个ceph-osd进程无响应或已死亡，并且相应的OSD已被标记down。幸存的ceph-osd守护程序将向监控器报告OSD似乎已关闭，并且在ceph health命令的输出中将显示新的状态，如下面的示例所示：

ceph health

HEALTH_WARN 1/3 in osds are down

每当有一个或多个OSD被标记为in和down时，都会提出此健康警报。要查看哪些OSD是down，请在命令中添加detail，如下面的示例所示：

ceph health detail

HEALTH_WARN 1/3 in osds are down
osd.0 is down since epoch 23, last address 192.168.106.220:6800/11080

或者，运行以下命令：

ceph osd tree down

如果存在驱动器故障或另一故障阻止特定ceph-osd守护程序运行或重新启动，则在其日志文件/var/log/ceph.

如果未设置ceph-osd下应存在错误消息。如果守护程序因心跳故障或suicide timeout错误而停止，则底层驱动器或文件系统可能无响应。检查dmesg输出和syslog输出以查找驱动器错误或内核错误。可能需要指定某些标志（例如，dmesg -T以查看人类可读的时间戳）以避免将旧错误误认为是新错误。

如果整个主机的OSD都down，请检查是否存在网络错误或主机的硬件问题。

如果OSD问题是由于软件错误（例如，失败的断言或其他意外错误）引起的，请在错误跟踪器，dev邮件列表存档和ceph-users邮件列表存档中搜索问题的报告。如果没有明显的解决方案或现有错误，则向ceph-devel邮件列表报告.

没有可用的驱动器空间

如果OSD已满，Ceph通过确保不会将新数据写入OSD来防止数据丢失。在一个正常运行集群中，当集群的OSD和池接近某些“满”比率时，会提出健康检查。阈值默认为mon_osd_full_ratio threshold defaults to 0.95（或95%的容量）：这是阻止客户端写入数据的点。阈值默认为mon_osd_backfillfull_ratio threshold defaults to 0.90（或90%的容量）：这是停止回填的点。阈值默认为mon_osd_nearfull_ratio threshold defaults to 0.85（或85%的容量）：这是提出OSD_NEARFULL健康检查的点。集群中的OSD在Ceph分配给它们的数据量各不相同。要通过显示每个OSD的数据利用率来检查“满”程度，请运行以下命令：

OSDs within a cluster will vary in how much data is allocated to them by Ceph. To check “fullness” by displaying data utilization for every OSD, run the following command:

ceph osd df

要通过显示集群的整体数据使用情况和数据在池中的分布来检查“满”程度，请运行以下命令：

ceph df

在检查ceph df命令的输出时，请特别关注最满的OSD，而不是原始空间使用的百分比。如果一个孤立的OSD已满，所有写入此OSD池的写入可能会失败。当ceph df报告池可用的空间时，它会考虑相对于最满的OSD的比率设置。要使分布更加均匀，有两种方法可用：（1）使用reweight-by-utilization命令逐步将数据从过度满的OSD移动到不足满的OSD，或者（2）在Luminous的后续版本中，利用ceph-mgr balancer模块自动执行相同的任务。

要调整“满”比率，请运行以下形式的命令或命令：

ceph osd set-nearfull-ratio <float[0.0-1.0]>
ceph osd set-full-ratio <float[0.0-1.0]>
ceph osd set-backfillfull-ratio <float[0.0-1.0]>

有时集群问题完全由于OSD故障引起。这可能是因为测试或集群很小、非常满或不平衡。当OSD或节点持有集群数据的大百分比时，组件故障或自然增长可能导致nearfull和full比率超出限制。在小型集群上测试Ceph对OSD故障的弹性时，建议留出充足的空闲磁盘空间，并考虑暂时降低OSDfull ratio，OSDbackfillfull ratio，和OSDnearfull ratio.

“满”状态 OSD 的输出中可见，如下面的示例所示：ceph health命令的输出中将显示新的状态，如下面的示例所示：

ceph health

HEALTH_WARN 1 nearfull osd(s)

详细信息，请添加detail命令，如下面的示例所示：

ceph health detail

HEALTH_ERR 1 full osd(s); 1 backfillfull osd(s); 1 nearfull osd(s)
osd.3 is full at 97%
osd.4 is backfill full at 91%
osd.2 is near full at 87%

要解决集群问题，建议通过添加OSD来增加容量。添加新的OSD允许集群重新分配数据到新可用的存储。搜索rados bench或浪费空间的孤儿。

如果传统的Filestore OSD因为已满而无法启动，可以通过删除满的OSD中的一小放置组目录来回收空间。

重要

如果您选择在满的OSD上删除放置组目录，不要在另一个满的OSD上删除相同的放置组目录。否则，您将丢失数据。您必须至少在至少一个OSD上维护您数据的一个副本。删除放置组目录是一种罕见且极端的干预。它不应轻易进行。

请参阅监视器配置参考 for more information.

OSD缓慢/无响应

OSD有时会缓慢或无响应。在排除这种常见问题时，建议在调查OSD性能问题之前消除其他可能性。例如，务必确认您的网络（网络）是否正常工作，验证您的OSD是否正在运行，并检查OSD是否正在限制恢复流量。

提示

在Luminous之前的Ceph版本中，up和inOSD有时不可用或运行缓慢，因为恢复OSD正在消耗系统资源。新版本提供了更好的恢复处理，通过防止这种现象。

网络问题

作为分布式存储系统，Ceph依赖于网络进行OSD对等和复制、从故障中恢复以及定期心跳。网络问题会导致OSD延迟和振荡的OSD。有关更多信息，请参阅振荡的OSD.

确保Ceph进程和Ceph相关进程连接并监听，请运行以下命令：

netstat -a | grep ceph
netstat -l | grep ceph
sudo netstat -p | grep ceph

要检查网络统计信息，请运行以下命令：

netstat -s

驱动器配置

一个SAS或SATA存储驱动器应该只托管一个OSD，但NVMe驱动器可以轻松托管两个或更多。然而，如果其他进程共享驱动器，则可能会出现读写吞吐量瓶颈。此类进程包括：期刊 / 元数据、操作系统、Ceph监控器，syslog日志、其他

由于Ceph在后期刊化写入，快速SSD是加速响应时间的吸引人的选择——尤其是在使用XFS或ext4文件系统为传统FileStore OSDs时。相比之下，Btrfs文件系统可以同时写入和期刊。 （但是，不建议在生产环境中使用Btrfs。）

Note

分区驱动器不会改变其总吞吐量或顺序读写限制。通过在单独的分区中运行期刊，吞吐量可能会有所提高，但最好还是在单独的物理驱动器中运行此类期刊。

警告

Reef不支持FileStore。Reef之后的版本不支持FileStore。任何提到FileStore的信息仅适用于Ceph的Quincy版本以及Quincy之前的版本。

坏扇区/碎片化磁盘

检查您的驱动器是否有坏块、碎片化和其他可能导致性能显著下降的错误。检查驱动器错误的工具包括dmesg, syslog日志，和smartctl（在smartmontools包中找到）。

Note

smartmontools7.0和晚提供NVMe stat passthrough和

共享监控器/OSD

虽然监控器是相对轻量级的过程，但当监控器与OSD在同一主机机器上运行时，可能会出现性能问题。监控器发出许多fsync()调用，这可能会干扰其他工作负载。当监控器在同一存储驱动器上与OSD共处时，性能问题的风险尤其严重。此外，如果监控器正在运行较旧的内核（预3.0）或没有syncfs(2)syscall的内核，则同一主机上运行的多个OSD可能会进行如此多的提交，从而破坏彼此的性能。这个问题有时会导致所谓的“突发写入”。

共享进程

由于进程向Ceph写入数据（例如，基于云的解决方案和虚拟机）而与OSD在同一硬件上运行，可能会导致显著的OSD延迟。因此，通常不建议将此类进程与OSD共处。相反，建议的做法是优化某些主机用于与Ceph一起使用，并使用其他主机用于其他进程。这种将Ceph操作与其他应用程序分离的做法可能会提高性能，还可能简化故障排除和维护。

在同一硬件上运行共享进程有时被称为“收敛”。在使用Ceph时，只有在专业知识和深思熟虑之后才能进行收敛。

日志级别

性能问题可能是由高日志级别引起的。操作员有时会提高日志级别以跟踪问题，然后忘记之后降低它们。在这种情况下，OSD可能会消耗宝贵的系统资源，将不必要的冗长日志写入磁盘。任何想要使用高日志级别的人都被建议考虑将驱动器挂载到日志的默认路径（例如，/var/log/ceph/$cluster-$name.log).

恢复限制

根据您的配置，Ceph可能会降低恢复速率以维护客户端或OSD性能，或者可能会增加恢复速率，以恢复影响客户端或OSD性能。检查客户端或OSD是否正在恢复。

内核版本

检查您正在运行的内核版本。旧内核可能缺乏提高Ceph性能的更新。

内核与SyncFS的问题

如果您遇到内核与SyncFS的问题，请尝试每个主机运行一个OSD，看看性能是否有所改善。旧内核可能没有足够新的glibc版本来支持syncfs(2).

文件系统问题

在Luminous之后的版本中，我们建议使用BlueStore后端部署集群。在运行Luminous之前的版本，或者如果您有特定原因要部署使用先前Filestore后端的OSD，我们建议XFS.

我们不推荐使用Btrfs或ext4指定的大小调整子卷配额。标志Btrfs文件系统有很多吸引人的功能，但错误可能导致性能问题和虚假的ENOSPC错误。我们不推荐ext4用于Filestore OSDs，因为xattr限制破坏了对长对象名的支持，而长对象名对于RGW是必需的。

更多信息，请参阅文件系统建议.

内存不足

我们建议每个OSD守护程序至少有4GB的RAM，我们建议从6GB到8GB进行舍入。在正常操作期间，您可能会注意到 of 4GB of RAM per OSD daemon and we suggest rounding up from 6GB to 8GB. During normal operations, you may notice that ceph-osd进程只使用了该数量的一小部分。您可能会想用多余的RAM来运行共处应用程序，或者在每个节点的内存容量上节省。然而，当OSD经历恢复时，它们的内存利用率会激增。如果在恢复期间没有足够的RAM可用，OSD性能将显著下降，守护程序甚至可能会崩溃或被LinuxOOM Killer.

阻塞请求或慢请求

当一个ceph-osd守护程序响应请求缓慢，集群日志会收到报告操作耗时过长的消息。警告阈值默认为30秒，可通过osd_op_complaint_time设置进行指数衰减。

配置。旧版本的Ceph抱怨old requests:

osd.0 192.168.106.220:6800/18813 312 : [WRN] old request osd_op(client.5099.0:790 fatty_26485_object789 [write 0~4096] 2.5e54f643) v4 received at 2012-03-06 15:42:56.054801 currently waiting for sub ops

新版本的Ceph抱怨slow requests:

{date} {osd.num} [WRN] 1 slow requests, 1 included below; oldest blocked for > 30.005692 secs
{date} {osd.num}  [WRN] slow request 30.005692 seconds old, received at {date-time}: osd_op(client.4240.0:8 benchmark_data_ceph-1_39426_object7 [write 0~4194304] 0.69848840) v4 currently waiting for subops from [610]

可能的原因包括：

  • 失败的驱动器（检查dmesg输出）

  • 内核文件系统中的错误（检查dmesg输出）

  • 集群过载（检查系统负载、iostat等）

  • 内核文件系统中的错误ceph-osd守护进程。

  • OSD碎片化配置次优

可能的解决方案：

  • 从Ceph主机中删除虚拟机

  • 升级内核

  • 升级Ceph

  • 重新启动OSD

  • 替换故障或故障组件

  • 覆盖OSD碎片化配置（基于HDD的集群使用mClock调度器）

调试慢请求

如果您运行ceph daemon osd.<id> dump_historic_ops或ceph daemon osd.<id> dump_ops_in_flight，您将看到一组操作和每个操作经历的事件列表。它们简要描述如下。

来自Messenger层的事件：

  • header_read: 消息使能者首次从线路上读取消息的时间。

  • throttled: 消息使能者尝试获取内存节流空间以将消息读入内存的时间。

  • all_read: 消息使能者完成从线路上读取消息的时间。

  • dispatched: 消息使能者将消息交给OSD的时间。

  • initiated: 这与header_read相同。两者共存是一个历史遗留问题。

来自OSD处理ops的事件：

  • queued_for_pg: op已放入其PG的队列中进行处理。

  • reached_pg: PG已开始执行op。

  • waiting for \*: op正在等待某些其他工作完成才能继续（例如，新的OSDMap；其对象目标的清理；PG的peering完成；如消息中指定的一切）。

  • started: op已被接受为OSD应该执行的操作，现在正在执行。

  • waiting for subops from: op已发送到副本OSD。

来自Filestore:

  • commit_queued_for_journal_write的事件：

  • write_thread_in_journal_buffer: op已分配给FileStore。

  • journaled_completion_queued: op在期刊的缓冲区中，正在等待持久化（作为下一个磁盘写入）。

来自OSD在数据已交给底层存储后的事件：

  • op_commit: op由主OSD提交（即写入期刊）。

  • op_applied: op已使用写入()到支持FS（即，在内存中应用但未刷新到磁盘）的主上。

  • sub_op_applied: op_applied，但副本的“subop”。

  • sub_op_committed: op_commit，但副本的subop（仅用于EC池）。

  • sub_op_commit_rec/sub_op_apply_rec from <X>: 主机在听到上述内容时标记此内容，但针对特定副本（即<X>).

  • commit_sent: 我们已向客户端（或主OSD，对于sub ops）发送回复。

虽然其中一些事件可能看起来是重复的，但它们跨越了内部代码中的重要边界（例如，将数据传递到新的线程中的锁内）。

使用mClock调度器的慢请求或慢恢复

Note

此故障排除仅适用于运行mClock调度器的基于HDD的集群，并且具有以下OSD碎片化配置：osd_op_num_shards_hdd= 5和osd_op_num_threads_per_shard_hdd= 1。另外，请参阅基于 HDD 的集群的 OSD 分片配置与 mClock的详细信息，该详细信息围绕更改默认OSD HDD碎片化配置的原因

在启用mClock调度器的基于HDD的集群扩展情况下，在多个OSD节点故障条件下，可能会报告或观察到以下内容：

  • 慢请求：这也表现为客户端I/O性能下降。

  • 慢后台恢复：低于预期的恢复吞吐量。

故障排除步骤：

  1. 通过OSD事件验证慢请求主要是类型queued_for_pg.

  2. 验证报告的恢复速率是否显著低于考虑背景恢复服务的QoS分配的预期速率。

如果上述任何步骤为真，则可以应用以下解决方案。请注意，这会中断，因为它涉及OSD重启。运行以下命令以更改基于HDD的默认OSD碎片化配置：

ceph config set osd osd_op_num_shards_hdd 1
ceph config set osd osd_op_num_threads_per_shard_hdd 5

上述配置不会立即生效，需要重新启动环境中的OSD。为了使此过程尽可能少中断，OSD可以仔细地交错重启。

振荡的OSD

“振荡”是指OSD被连续快速标记为up首先和down的现象。本节解释如何识别振荡，以及如何减轻它。

当OSD对等和检查心跳时，它们使用集群（后端）网络，前提是它可用。参见监控器/OSD 交互 for details.

上游Ceph社区传统上建议分离公共（前端）和私有（集群/后端/复制）网络。这提供了以下好处：

  1. 分离（1）心跳流量和复制/恢复流量（私有）与（2）来自客户端和OSD与监控器之间的流量（公共）。这有助于防止一个流量流DoS另一个，这反过来可能导致级联故障。

  2. 公共和私有流量都增加了额外的吞吐量。

在过去，当常见的网络技术被测量在一个包括100Mb/s和1Gb/s的范围时，这种分离通常至关重要。但随着今天10Gb/s、40Gb/s和25/50/100Gb/s的网络，上述容量问题通常已减弱甚至消除。例如，如果你的OSD节点有两个网络端口，将一个分配给公共网络，另一个分配给私有网络，这意味着你没有路径冗余。这降低了您在不影响集群或客户端的情况下承受网络维护和网络故障的能力。在这种情况下，考虑改为仅使用两个链路进行公共网络：使用绑定（LACP）或等价路由（例如，FRR），您将获得增加吞吐量裕量、容错性和减少OSD振荡的好处。

当私有网络（甚至单个主机链路）失败或退化而公共网络继续正常运行时，OSD可能无法很好地处理这种情况。在这种情况下，OSD使用公共网络向监控器报告彼此down，同时将自己up标记为。监控器随后在公共网络上发出更新集群映射，其中受影响的OSD被标记down。这些OSD会向监控器回复“我还没死呢！”，然后循环重复。我们称此场景为“振荡”，它可能很难隔离和纠正。如果没有私有网络，这种令人烦恼的动态就可以避免：OSD通常要么up或down没有振荡。

如果确实有某事导致OSD“振荡”（连续被标记down然后又up再次），您可以通过暂时冻结它们的状态来强制监控器停止振荡：

ceph osd set noup      # prevent OSDs from getting marked up
ceph osd set nodown    # prevent OSDs from getting marked down

这些标志记录在osdmap中：

ceph osd dump | grep flags

flags no-up,no-down

您可以使用以下命令清除这些标志：

ceph osd unset noup
ceph osd unset nodown

还有两个其他标志，noin和noout，它们防止启动OSD被标记in（分配的数据）或保护OSD最终被标记out（无论mon_osd_down_out_interval).

Note

noup, noout, and nodown的当前值如何）被标记。标志是临时的，因为清除标志后，它们所阻止的操作应该很快就可以执行。但noin标志防止OSD在启动时被标记in任何在设置标志时启动的守护程序将保持这种状态。

Note

振荡的原因和影响可以通过对mon_osd_down_out_subtree_limit, mon_osd_reporter_subtree_level, and mon_osd_min_down_reporters进行仔细调整来在一定程度上减轻。最佳设置的推导取决于集群大小、拓扑和使用的Ceph版本。所有这些因素的相互作用微妙，超出了本文档的范围。

由 Ceph 基金会带给您

Ceph 文档是一个社区资源，由非盈利的 Ceph 基金会资助和托管Ceph Foundation. 如果您想支持这一点和我们的其他工作，请考虑加入现在加入.