我有一个似乎以一种有趣的方式陷入困境的过程。顶部显示：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
38984 gergely 20 0 332m 276 184 S 0.7 0.0 18:13.16 Holmake
79492 gergely 20 0 10.7g 6.5g 316 D 0.7 84.5 107:04.76 buildheap
buildheap 总共使用了 84.5% 的物理内存和 10.7 GB 的虚拟内存。这是在分配了 8GB 物理内存的机器上。但进程本身仅使用 0.7% 的 cpu 周期。
/proc/79492/stat 中的第 12 个变量是 336236。这是否太高了？
$ cat /proc/79492/oom_score
333
同样，尚不清楚这是否太高。
这是否显示出太多的颠簸？
而且，除了要求系统管理员为机器分配更多物理内存之外，还有其他解决方法吗？
答案1
我不认为内存耗尽是问题所在。如果是的话，我希望看到进程被内核 OOM（内存不足）杀手终止，或者 dmesg 中的页面分配错误。还要记住，内存的过度使用和交换是“正常的”，尽管有明显的性能影响。
查看实际情况的最简单方法是使用 strace 转储进程系统调用。
strace -p <PID>将 strace 附加到正在运行的进程，“-p”选项用于进程的 PID。
或者，您可以直接使用 strace 运行程序：
strace buildheap
如果运气好的话，您将能够看到进程正在等待什么，例如尝试读取它无权访问的文件。