主页 / server / 问题 / 1159190
Accepted
MikeKulls
Asked: 2024-05-10 16:50:25 +0800 CST

如何查找 SSD 的磨损情况

  • 772

我们有 8 台 Cisco 服务器，其中 12 个用于数据的旋转磁盘和 2 个用于操作系统的 SSD。这 2 个 SSD 位于 Linux 软件 raid 1 中。这些 SSD 的磨损指示器均为个位数，其中一些达到 1 的值已发生故障。我正在将它们全部从备件中更换（这是一个漫长而烦人的过程），但我注意到磨损指标每周下降 1% 或 2%（我没有进行精确测量）。这些服务器上运行着一个应用程序，供应商给了我一些模糊的想法，但我确实需要找到它正在写入的目录。这样我就可以真正突出问题并敦促供应商进行修复。我搜索了一些，但没能找到太多。例如，iotop 显示完整磁盘吞吐量，包括 12 个旋转磁盘。操作系统是Redhat 7.9

回答一些问题：

  • 磁盘为“480GB 2.5 英寸企业价值 6Gb SATA SSD”
  • 产品 ID 为“UCS-SD480GBKS4-EB”
  • 2018 年服务器标配磁盘
  • 最近磨损似乎加速了（我现在正在记录磨损情况，所以几天后就会有更好的答案）
  • 我已经用几年后购买的相同磁盘替换了大多数磁盘。
  • iotop 显示稳定的 8MB/s 写入速度。
  • 该系统在 8 台服务器上运行 hadoop。hadoop 文件系统位于旋转磁盘上，因此不应接触 SSD
  • 根据供应商的建议，我已经大大减少了磁盘 IO，尽管它看起来仍然很高（8MB/s）
redhat

4 个回答

  1. 如果没有有关系统寿命、SSD 的确切型号和寿命以及一些其他因素的更多详细信息，很难确定。

    假设 SSD 质量良好，一周内磨损指标为 1-2% 意味着您在一周内向其中写入几TB （最少）的数据。对于操作系统卷来说，这是一个巨大的数据量。我要考虑的罪魁祸首按顺序是：

    • 便宜的SSD。简而言之，听起来很像您在该系统中没有特别优质的 SSD，这将使 1-2% 的预期使用寿命转化为多个 TB 数据的假设无效。我建议对您使用的 SSD 的确切型号进行一些研究，以确认其实际额定寿命写入耐久性是多少，并且没有记录的固件问题。过去五年左右的好产品的评级应至少是其所列容量的 100 倍（因此 1 TB SSD 至少为 100 TB），但理想情况下不止于此（作为比较点，当前的高端消费者如今，1 TB SSD 的额定写入量通常约为 300 TB）。
    • 块设备缓存。如果您有 bcache、dm-cache、ZFS L2ARC 或其他一些正在使用 SSD 上的空间的块设备缓存设置，这可能是罪魁祸首，请尝试将其关闭，看看会发生什么（好吧，除了可能对 SSD 造成严重影响之外）表现）。
    • 记录。您的大部分日志可能都位于操作系统卷上。如果您打开了详细日志记录，并且您的应用程序非常繁忙，那么一周内可能会轻松达到 TB 范围。但它也可能是其他东西，比如来自 SELinux 的日志、进程记帐或审计守护进程。
    • 非块缓存。本质上，是在/var/cache可能存储缓存的位置或其他位置（例如~/.cache用户主目录中）的内容。除非它是一个非常活跃的终端服务器，否则这不应该达到所需的数字，但值得检查。
    • 交换。可能不是主要贡献者，因为达到所需的数量将转化为足够频繁的交换，从而导致系统上的其他性能问题。
    • 13

  2. 检查交换——这是一个典型的指标。检查您是否运行任何软件的临时文件 - 这可能是另一个软件。两者都需要您检查，并且考虑到临时文件依赖于软件 - 没有真正的帮助。构建服务器目录是我上次观察到的地方 - 技术上是一个临时结构，因为每次运行都会下载存储库（好吧，更新它），然后初始化源树并构建 - 这是大量写入。最终用户 SSD 不是为此而设计的。确实取决于软件 - 不可能有通用答案。

    否则，请考虑是否适合开始使用低端 SSD - 这听起来比应有的下降更多

    • 11
  3. Best Answer

    您可以使用 ProcMon for Linux 来跟踪文件系统调用。

    https://github.com/Sysinternals/ProcMon-for-Linux

    • 5

  4. 您可以自上而下地解决这个问题。

    这意味着首先设置一个监控，例如netdata，它将所有相关 IO 指标持续写入所有服务器的数据库中。

    使用该数据，您可以检查交换活动以及 SSD 看到的写入量以及它随时间的变化情况。

    这样您就可以交叉检查磨损指标的变化是否确实合理。我的意思是，SSD 固件中影响 SMART 报告的错误并非闻所未闻。

    为了识别高速写入的目录和文件，您可以filetop从bcc-tools包运行，例如：

    # /usr/share/bcc/tools/filetop
23:56:12 loadavg: 1.32 0.83 0.60 4/1273 563644

TID     COMM             READS  WRITES R_Kb    W_Kb    T FILE
563614  yes              0      36757  0       294056  R foo.bar
[..]
    • 2

相关问题