带有 dtrace 错误的高写入 I/O“脉冲”

Posted 2023-03-06

【中文标题】带有 dtrace 错误的高写入 I/O“脉冲”

【英文标题】：High Write I/O "Pulsing" with dtrace errors

【发布时间】：2013-07-03 12:58:34

【问题描述】：

我们大约每 10 秒经历一次“脉冲”写入磁盘（从 1 次写入/秒脉冲到 142+ 次写入/秒）。

查看此示例图片： https://discussions.apple.com/servlet/JiveServlet/showImage/2-22394173-269851/Screen+Shot+2013-07-03+at+13.22.28.png

我们深入研究了这些“脉冲”写入，发现它们与 IOTOP 的这些错误发生的时间完全相同：

dtrace: error on enabled probe ID 5 (ID 992: io:mach_kernel:buf_strategy:start): illegal operation in action #3 at DIF offset 0

“脉冲”仅在上述错误出现在 IOTOP 中时才会发生。

注意：我们正在为两个驱动器运行 Apple RAID 软件镜像。

我们将不胜感激任何建议、帮助和提示。提前致谢。

【参考方案1】：

您看到的脉冲 I/O 模式是其中许多/大多数文件系统写入是异步的应用程序的特征 - 这是因为文件系统会批量写入，因此它可以同时执行许多操作以避免执行一个磁盘每次写入寻找。我能想到的最常见的例子是数据库写入数据——除了数据库的预写日志外，所有内容通常都是异步写入的；其他事务访问模式往往是相似的，因为如果某些异步写入在崩溃中丢失，它们有一个预写日志来恢复。这是一种常见的访问模式，不一定是问题，但是当您的磁盘高度碎片化并且文件系统无法批量写入所有内容时（导致多次查找，就像它试图避免的那样），它可能会成为问题.

您看到的 DTrace/iotop 错误意味着 DTrace 实现本身或 iotop DTrace 脚本中存在错误。查看iotop 的源代码（在OS X 上的/usr/bin/iotop 中），有三个io:::start 回调可能是罪魁祸首。对于某些类型的 I/O，脚本中可能存在某种类型的空指针访问，但根据脚本和 io:::start 探测所采用的参数，它看起来不太可能。也许最好通过向 Apple 报告错误来解决这个问题。

【讨论】：

非常感谢您提供的信息丰富的评论。我对它进行了更深入的研究，似乎是 mysql 导致了这些沉重的脉冲写入。当一个表添加或更新了一个条目时，它是否必须将整个表重新写入磁盘，或者它是否可以附加/修改现有数据？我们正在使用 MyISAM 表。我们还使用带有 ORDER BY 和 TEXT 字段的 SELECT 查询，这当然需要写入临时磁盘表，但是它们不会被轮询，它们会在请求进入时被写入。非常感谢诊断此问题的任何帮助.

好吧，深入挖掘，我找到了问题的确切原因。似乎 OS X 中的 launchd 正在写入磁盘（可能是 OS X 中的磁盘日志）：17:55:09.274758 IOCTL <DKIOCSYNCHRONIZECACHE> /dev/disk2 0.073689 W launchd.263*