但是发现top中不能使用c命令查看这个进程的命令行，因此只能进入/proc 目录看看有没有人品能看到该进程使用的一些fd（文件描述符，file descriptor），结果发现人品不错，通过cp复制出来的/proc/24602中找到了task目录下的fd，如下图所示：
图9：通过fd找到这个进程属于哪一个应用里面的
[img][/img]
发现出问题的这个应用程序就是前天同事问我的那个，也是研发人员说存在问题的那个应用。经过昨天晚上的重启后发现，此进程的内存占用率依然很高，初步判断是程序的问题，当然也要检查一下IO问题，但是Ubuntu这个系统比较奇怪，系统日志中对此没有任何可用的信息，而java程序中产生的日志太多、信息太杂还是让更专业的开发人员去查吧。
到现在，问题的始作俑者算是找到了，但是为什么是由于IO问题导致还没找到原因，从上午开始写此文到现在，写此文之前已经告诉有关研发人员去分析代码去了，现在去问了下，初步定位在程序内部有一个模块存在死循环（不断的查询远端数据库）导致的，具体怎么改和深入测试还需要一些时间。
图10.1：昨天晚上该程序（图中pid为2988）的内存占用为1.4GB左右，符合常理，但今早上就11GB了（截图之前有过13GB、12GB的记录）
[img][/img]
图10.2：最新截图，又13GB了。
[img][/img]
图11：问题处理的总体思路如下图所示：
通过此次事件，总结经验如下：
1.通过fd判断进程的cmd，除此之外，top -c，pstree -a，ps -ef等
2.通过strace命令分析进程在哪里等待
3.了解进程的D状态
tag:strace命令用法,进程状态D,Linux进程分析,Linux进程调试,strace调试程序