linux 系统统计进程打开文件数方法

1 打开文件数各参数含义

参考  https://blog.csdn.net/xifeijian/article/details/9088137

查看某进程打开文件数

need-to-insert-img

2 统计文件所有进程文件数

lsof | awk '{print $2,$1}' | sort | uniq -c | sort -rn >>b.txt

need-to-insert-img

3 统计pid 进程打开的文件数

lsof -p pid

need-to-insert-img

4 统计pid 进程打开所有的文件数

lsof  |  awk "{print $NF}" | grep 10555  >product.txt

need-to-insert-img

5 分析pid 进程打开文件数连接  排序 和 统计

awk '{print $NF}' product.txt |sort |uniq -c |sort -nr >sort2.txt

need-to-insert-img

从接触unix开始就一直听到和遇到core dump，特别是刚学着使用C语言在AIX下编写程序的时候，core dump更是时不时就会不请自来。记得当时刚写应用的时候，提交程序时最怕的就是在运行过程时遇到core dump，对于银行核心系统，特别是使用静态应用进程，如果一个相对频繁一点的交易导致core dump，那么毫无疑问，除了赶紧定位错误改程序外，重启进程甚至无法争取到多少缓冲的时间来进行代码的更正和测试。而且往往导致core dump的，就是程序中一个小小的未注意到或者未测试到的一个疏忽。

虽然常常遇到core dump，不过很长时间内，都是出于知道这个名字，知道它导致的后果，知道一部分导致它出现的原因，其他的就都不甚了了了。说起来，就是自己太懒了，懒得看书......少壮不努力啊。看过一则统计，说60岁以上的老人，超过70%都后悔少壮不努力，不知统计的数据能否反映整个社会的情况。不过总的来说，这句古话还是有些道理的。大家不要学我。哈哈

core dump，翻译过来讲，就是核心转储。大致上就是指，如果由于应用错误，如浮点异常、指令异常等， *** 作系统将会转入内核的异常处理，向对应的进程发送特定的信号（SIGNAL），如果进程中没有对这些信号进行处理，就会转入默认的处理，core dump就是其中的一种。如果进程core dump，系统将会终止该进程，同时系统会产生core文件，以供调试使用。这个core文件其实就是内存的映像，即进程执行的时候内存的内容，也就是所谓的core dump。平常大家说某某进程core dump了，其实主要的意思就是说：某某进程因为错误而被系统自动终止了。

AIX上提供了dbx工具可以对core dump进行调试，协助定位引起core dump的代码。最普通的语法是：

dbx 应用名 core文件， 然后使用where命令来显示调试信息

一般来讲，根据工作中遇到的情况，dbx还是能够比较轻松的根据提示的内容来定位代码的。不过也有一些特殊情况时，dbx显示的调试信息过于模糊或者不直观，这个时候就只能根据经验来逐步定位了。有时定位起来会耗用相当长的时间。遇到这种情况时，使用日志文件，通过在代码中穿插多个写log的语句，也可以协助发现。因为进程core dump时，日志当然也中断了，根据日志在哪个代码行之后或之前中止了，可以有效缩小寻找的范围。甚至，在有些情况下，使用日志定位是唯一简便的方法了。

---