我管理的几个 Linux 系统上有一些 I/O 问题。它们表现为进程经常在诸如 open()、unlink() 或 close() 等简单的系统调用中阻塞长达几秒钟（这是一个问题，因为一些相关程序需要相当低的 I/O 延迟才能正常运行）。确实，有问题的系统会经历一些中等的 I/O 负载，但我认为这不足以证明如此巨大的延迟时间是合理的。有时，调用可能需要超过 15 秒才能完成（尽管更常见的情况是它们可能需要 1 秒、2 秒或 3 秒左右）。
我的问题是：我如何才能找出发生这种情况的原因？我想要一些工具，它可以告诉我内核中相关进程被什么阻止，以及它们休眠的进程为什么很忙，发生了什么事情，等等。有这样的工具吗，或者有其他方法可以尝试调试发生了什么？
当然，如果你知道到底是什么是发生了，怎样才能避免？
顺便说一下，我使用的文件系统是 XFS。
答案1
现在，我已经设法自己解决了这个问题，所以我至少可以自己跟进，以供后人参考。
不幸的是，我在内核升级时解决了原来的问题，但又出现了新的问题，性能更差，而且同样难以追踪。我发现的技术如下：
首先，blktrace/blkparse是一个我发现非常有用的工具。它允许跟踪单个 I/O 请求的进度，并提供许多有用的详细信息，例如提交请求的进程。将输出放在 上很有用tmpfs，这样跟踪存储的处理就不会自行开始跟踪。
不过，这只能起到一点帮助，所以我编译了一个具有更多调试功能的内核。特别是，我发现ftrace非常有用，因为它允许我跟踪内核空间内性能不佳的进程，查看它做了什么以及在哪里被阻塞。编译调试内核还可以提供工作WCHAN输出ps，这可以作为一种更简单的方法来查看进程在内核中正在做什么，至少在更简单的情况下是这样。
我也希望延迟顶部很有用，但我发现它有很多错误，而且不幸的是，它只显示太“高级”而无法真正有用的延迟原因。
iostat此外，我发现它比简单地以非常近的时间间隔查看内容更有帮助/sys/block/$DEVICE/stat，就像这样：
while :; do cat /sys/block/sda/stat; sleep .1; done
请Documentation/iostats.txt参阅内核源代码树以了解文件的格式stat。通过近距离查看，我可以看到 I/O 突发的准确时间和大小等。
最后我发现，升级内核后出现的问题是由于稳定页面这是 Linux 3.0 中引入的一项功能，在我的案例中，当 Berkeley DB 在其 mmap'ed 区域文件中弄脏页面时，会导致其长时间停机。虽然似乎可以修补此功能，并且它导致的问题可能会在 Linux 3.9 中得到修复，但我已经解决了目前遇到的最严重的问题修补 Berkeley DB允许我将其区域文件放在不同的目录中（就我而言/dev/shm），从而使我完全避免了这个问题。
答案2
根据我的经验，你可以安装最简单、最详细的统计工具来追踪神秘的系统性能问题http://freecode.com/projects/sysstat又名 sar
当然，您也想查看 iostat 命令输出，特别是在正常系统负载（低于 1.0 左右）下您的 %iowait 应该低于 5-10%。
查看 ps 输出，如果在 STAT 列中看到 D 状态，则表示这些进程已被锁定并正在等待 IO，很可能是控制器或磁盘的硬件问题，请检查 SMART 统计信息以及 dmesg 和 syslog 以查找线索
检查 sar 日志并确定高峰时间（如果发生这种情况），并尝试将这些时间与磁盘密集型 cron 作业（例如通过网络备份）相匹配
你可以使用 bonnie++ 来对磁盘性能进行基准测试
答案3
尽管这个问题已经存在好几个月了，我还是想提一下 strace。它可能会帮助到遇到类似问题并找到此页面的人。
尝试。
strace "application"
你也可以
strace -e read,write "application"
仅显示读/写事件。
应用程序将正常加载（尽管启动速度稍慢），您可以正常使用它来触发问题。输出将显示在您用于启动 strace 的 shell 中。
strace 的优点是，您可以看到应用程序触发减速时最近的函数/内核调用。您可能会发现，如果您的/home帐户在 NFS 上，则由于某种原因，应用程序在通过 NFS 进行文件 I/O 时会遇到一些困难。