有同学深入查看了下，如下:
http://www.makeinstall.cn/index.php/archives/156
netstat和web主机socket文件分析(二)
转载请注明出处，from www.makeinstall.cn
在上一篇，我们发现了netstat的一个bug，即作者未充分考虑到scoket的inode可能很大，以至超过int的最大值。但是，更让人感兴趣的问题出现了：web前段机器上的socket inode号为什么会大到十位数，而其它机器上的几乎都只是八位数。
3. VFS和socket inode分析
首先，我们需要了解socket的inode是什么。
socket文件的inode存在于Linux的VFS虚拟文件系统中。VFS是一个异构文件系统之上的软件粘合层，可以让open()、read()、write()等系统调用不用关心底层的存储介质和文件系统类型就可以工作。通过VFS，一个抽象的通用访问接口屏蔽了底层文件系统和物理介质的差异性，每一种类型的文件系统代码都隐藏了实现的细节。对于VFS层和内核的其它部分而言，每一种类型的文件系统看起来都是一样的。
VFS inode和磁盘文件系统中的inode不同。比如ext2文件系统，它的inode位于磁盘上划分的块组中，每个inode 128字节。在分割扇区时，系统会先做出一堆inode供以后使用，inode 的数量关系着系统中可以建立的文件及目录总数。磁盘上的每个文件都有且仅有一个inode，即使文件中没有数据，inode也是存在的。
VFS inode只存在于内存中，可以通过inode缓存访问。每个文件在VFS中都有相应的inode结点，包括普通文件、目录以及特殊文件，如socket、pipe等。在需要某个文件的时候系统会在内存中为其建立相应的inode数据结构，建立的inode结构将形成一个链表，可以通过遍历这个链表去得到我们需要的文件结点。但是，VFS对于不同文件的inode号分配方式是不同的。具体如下：
- 对于ext2等磁盘文件系统中的普通文件，每个文件在磁盘上都有对应的inode，该inode号也是已知的。在访问这些文件时，VFS会在内存中为这个文件分配VFS inode，将在磁盘文件系统中确定的inode号赋给inode结构。可见，一般普通文件的inode号都不会太大。
- 对于socket等特殊文件来说，并没有像磁盘文件一样的inode号的来源，内核在实现中维护了一个unsigned long型的静态变量来保存目前分配的inode号的最大值，新分配的inode号在此基础上加1来实现。这个静态变量的值会一直增大而不会减小，直至机器重启。
知道了socket文件inode的分配方式，我们可以假设，在某台机器上，socket文件被频繁的创建（并关闭），则新产生的socket文件对应的inode号会以较快的速度增大，在经过足够长的时间后，inode号的大小会超过INT_MAX的值，这是如果运行netstat -nlp则无法得到其程序名。
这样的假设确实出现在了web前端机器上。Web全段机器每天负责响应大量用户的连接请求，每个连接都需要通过建立socket来进行通信，这导致socket的inode号会一直快速增长下去。统计了一台的socket inode的情况，记录了在5天内每天同一时间的socket inode最大值，分析得到每天大约会增大70,000,000左右。
很显然，socket inode的增长情况和前端机器流量在各时段的分布是一致的。这也证明前端机器极大的流量使得socket文件极频繁的创建，导致了在前端机器上出现了超大的inode。
socket过大除了对netstat的显示结果造成影响外，会不会大到超过unsigned long的最大值而产生问题呢？答案是不会，在线上64位的机器上，unsigned long的最大值是20位数，以每天70,000,000的增量，要达到ULONG_MAX是不可能的。
4. 解决方案对于因socket过大导致netstat –nlp不能显示PID/Program name的问题，有没有什么解决方法或者替代方案呢？
- 修改netstat源码，去除对socket inode最大值判断的限制；
- 使用lsof命令来查看监听在某个端口的进程，如： $ /usr/sbin/lsof -i :端口号