我在我管理的几个Linux系统上遇到一些I / O问题。它们表明，在文件上的open（），unlink（）或close（）这样的简单系统调用中，进程通常会阻塞长达几秒钟的时间（这是一个问题，因为某些涉及的程序需要相当低的I / O延迟才能进行操作）正确地）。确实，所讨论的系统经历了适度的I / O负载，但是我很难认为足以证明如此巨大的等待时间。有时，通话可能需要15秒钟以上才能完成（尽管更常见的是，通话可能需要1或2或3秒钟左右）。
我的问题是：我怎么找出为什么会这样？我想要的是一个工具，可以告诉我内核中所阻止的进程是什么，以及为什么休眠的进程很忙，发生了什么事情等等。有没有这样的工具，或者有其他方法可以调试发生的事情吗？
另外，当然，如果您有任何线索，其实什么是发生的事情，怎么能避免？
作为记录，我使用的文件系统是XFS。
Answers:
现在，在适当的时候，我已经设法解决了这个问题，因此，我至少可以自己对其进行后续工作。
不幸的是，我在内核升级中失去了最初的问题，但是却换了一个新的内核，性能更差，而且很难追踪。我发现的技术如下：
首先，blktrace/ blkparse是我发现非常有用的工具。它允许跟踪具有许多有用细节的单个I / O请求的进度，例如提交请求的过程。将输出放在上是有帮助的tmpfs，这样就不会开始跟踪自身对跟踪存储的处理。
但是，到目前为止，这只是有帮助，所以我编译了具有更多调试功能的内核。特别是，我发现ftrace它很有帮助，因为它使我能够跟踪内核空间内性能不佳的进程，以查看其作用以及在何处阻塞。编译调试内核也为它提供了有效的WCHAN输出ps，至少在更简单的情况下，它可以作为查看内核内部进程正在执行的一种更简便的方法。
我也希望LatencyTop有用，但是我发现它有很多问题，而且不幸的是，它只显示了太“高级”的延迟原因，以至于无法真正有用。
另外，我发现它比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），让我完全避免了这个问题。
根据我的经验，可以安装用来追踪神秘的系统性能问题的最简单，最详细的统计工具是http://freecode.com/projects/sysstat aka。萨尔
确保您也要查看iostat命令输出，特别是在正常系统负载（低于1.0左右）下，您的％iowait应该低于5-10％。
查看ps输出，如果在STAT列中看到D状态，这意味着这些进程已锁定并正在等待IO，很可能是控制器或磁盘出现硬件问题，请检查SMART统计信息以及dmesg和syslog以获取线索
检查sar日志并确定高峰时间（如果发生这种情况），并尝试将这些时间与磁盘密集型cron作业进行匹配，例如通过网络进行备份
您可以使用bonnie ++对磁盘性能进行基准测试