我们有这个 apache 进程，它不时会成为 io 绑定。使用 atop，我们可以看到它是一个写入操作。
使用lsof -p <PID>我们可以看到 httpd 进程打开的文件列表。首先我们认为“日志”文件一定是问题所在。所以我们关闭它们只是为了测试。然而写入操作仍在继续。
我们将继续测试其他一些东西。例如，我们经常使用 php 会话变量。也许 php 会话文件正在获取所有写入数据。
但是有没有办法快速识别由 httpd 进程写入的文件？这样我们就可以集中精力处理这些文件。
更新：
我们按照建议使用了 strace 命令。以下是输出中的两行。
write(23, "\27\0\0\0\3SET CHARACTER SET utf8", 27) = 27
write(23, "\17\0\0\0\3SET NAMES utf8", 19) = 19
我们在这个服务器上没有 mysql 进程。那么 strace 是否也显示了写入以太网端口的内容？
UPDATE2：在高 io 负载期间，消耗大部分写入资源的进程会给出以下输出strace -e trace=write -p <PID>：
--- SIGCHLD (子进程退出) @ 0 (0) ---
write(9, "!", 1) = 1
write(19, "OPTIONS * HTTP/1.0\r\nUser-Agent: Apache (内部虚拟连接)\r\n\r\n", 70) = 70
然而我无法弄清楚这些被写入到哪里。
UPDATE3：尝试以下命令，它将显示所有打开以供写入的文件：
lsof | grep -e "[[:digit:]]\+w"
和下面是我无法检查的仅有的两行。其他文件没有显示任何显著的写入活动。下面的项目是否可能被暂时写入硬盘？
httpd 14173 apache 9w FIFO 0,6 205676000 pipe
httpd 14173 apache 1w CHR 1,3 3346 /dev/null
找到原因：
我们最终发现 io-boundness 的原因是 php 会话文件。将 php 会话文件移动到另一个硬盘驱动器也会立即将 io-boundness 移动到该硬盘驱动器。我们可能会将会话移动到 redis 或其他基于内存的系统。有趣的是，尽管下面的答案在技术上是正确的，但它们并没有引导我们找到会话文件，而是让我们继续查看系统的不同点。
答案1
strace -e trace=write -p <PID>
答案2
我认为 lsof 是查看当前打开的文件的最佳工具
lsof -p <pid>
答案3
您确定要查看正确的进程吗？每个 Apache“服务器”都是一个单独的进程，因此您应该在每个子进程上循环控制（从指令中定义的编号开始StartServers）。
要查看连接：
netstat -nap | grep <pid>