如何剖析java进程触发的IO活动？

Question

目前，我知道有一些工具可以分析 java 进程的 CPU/内存。

当我想跟踪 java 进程如何与 IO 交互时，我没有找到任何工具来检查细节，尤其是哪些线程/调用堆栈、用法和文件。

我可以使用的工具是一些操作系统级别的命令，如

dstat

.

是否有用于分析 Java 磁盘 IO 的工具？

Answer 1

是否有用于分析 Java 磁盘 IO 的工具？

一些 JVM 分析器具有处理文件访问的探测器。 JProfiler 例如有一个文件探测器，可以测量 java.io 和 java.nio 的读写操作。

测量由文件解决：

出于性能方面的考虑，文件探测的热点视图显示了哪些文件花费在磁盘 I/O 上的大部分时间，并为您提供每个文件的可扩展回溯。

免责声明：我公司开发JProfiler

Answer 2

非常规但简单。只要做this.

很难找到一个分析器 a) 在挂钟时间而不是 CPU 时间工作，b) 对调用堆栈进行采样，而不仅仅是 IP，c) 需要少量样本而不是大量样本。

记住，你的首要目标是定位问题，这样你就可以解决它，而不仅仅是计时，而是想知道它是什么。 问题越大，随机停止的可能性就越大，并准确地告诉您它在做什么以及为什么。

问题有多大？如果一个问题花费了 X% 的时间，那么修复它最多可以节省 X%。那么，如果 X 为 10% 或更少，何必呢？假设 X% 大于 10%，那么每个样本都有那个概率落在里面。所以如果你取 N 个样本，它出现在问题中的次数是 N 乘以 X%（平均值）。

你需要多少样品？好吧，如果您看到该程序在一个样本上做了一些浪费的事情，那么您是否发现它是值得怀疑的。但是如果你看到它在 two 样本上做同样的浪费事情，统计数据表明你已经找到了问题！而且在你看到问题之前N越小，它就越大！你知道它到底有多大吗？不，你不在乎，因为你知道它大到可以修好。 （如果你想要更多的信息，就取更多的样本。我从不取超过 20 个。）（之后你总是可以用一个简单的计时器来测量加速比。）

问题不止一个吗？你打赌有！如果你解决了一个问题，它会让剩下的问题变得更大！例如，可能有两个问题，问题 A 的成本为 50%，问题 B 的成本为 25%。第一次看，你找到问题 A，解决它，现在问题 B 的成本是 50%，而不是 25%。修复这两个问题，你的速度就会提高 4 倍。 （这就是放大效果。） （如果你碰巧先修复 B，没问题。现在 A 是 67% 的时间。）
道德：在找不到可以修复的东西之前，不要停止寻找和修复。

探查器通常发生的情况是，他们发现的东西并不多，而且/或者你无论如何也无法修复。就像一些晦涩的图书馆例程中的 5%。这会让程序员失望吗？不。这让他们快乐，因为这似乎告诉他们他们的代码是最优的！ 这是一个悖论吗？是的。 分析器很受欢迎正是因为它们不起作用！

Answer 3

如果您的目标是找到 Java 应用程序（包括 IO）中的瓶颈，我还建议尝试 Mike Dunlavey 在他的回答中已经指出的“穷人的侧写”技术：

1. 以真实的工作负载运行应用程序并进行线程转储。
2. 重复几次，直到找到规律。 （如果有明显的瓶颈，程序很可能在昂贵的操作期间被中断。）

如何在 Java 中获取堆栈跟踪？如果你有进程的 PID，你有两个选择：

1. 运行

   kill -3 PID

   使进程在标准输出上打印堆栈跟踪
2. JDK 包含一个名为 jstack 的工具来获取线程转储：

   jstack PID

根据我的经验，这种简单的技术非常强大并且不需要设置。开销也很低，因此您可以在生产中安全地使用它。

如果您使用的是 Linux，另一种方法是使用 perf top 进行实时分析：

sudo perf top

perf 往往更适合 C++ 等本机编译语言，但如果您无法从 Java 线程转储中获取任何信息，则值得一试。由于 perf 在内核级别工作，它还可以揭示 IO 中的瓶颈。同样，开销很低，因此您可以在生产环境中运行它（具有实际的工作负载）。

Answer 4

我在 Linux perf 上取得了不错的成绩。它可以测量所有 IO 活动的时间并获取堆栈跟踪。

我没有在 java 中使用它，但我读到如果你用

-XX:+PreserveFramePointer

编译，堆栈跟踪和符号将起作用。