socket乱用代码诊断工具

最新推荐文章于 2024-09-14 18:46:05 发布

trtrtg

最新推荐文章于 2024-09-14 18:46:05 发布

阅读量1.1k

点赞数 18

分类专栏：实用工具文章标签： java tcp

本文链接：https://blog.csdn.net/trtrtg/article/details/141114214

版权

实用工具专栏收录该内容

7 篇文章 0 订阅

订阅专栏

Socket端口乱用诊断工具

目标

找出程序中导致“too many files open”或“文件打开过多”问题的代码

适用范围

JDK1.6 +

背景

某客户多次出现这类问题，也调整过限制数，隔一段时间仍然出现。有理由怀疑程序存在问题，而单从业务日志方面分析无法问题根源，需要结合内核日志精准定位问题。

工具介绍

network_port_monitor工具是一个脚本工具，用于汇总本地端点使用情况，部署在服务器上，用于监控本地的进程。当发现某个进程出现“too many files open”，可针对性的监控处理。

工作原理

通过监控服务器本地进程一段时间内的网络调用，收集网络日志并汇总本地端口使用情况。后开发人员根据网络日志、汇总日志联合业务日志和堆栈进行分析、优化。使用网络端口监控工具整体分析流程如下所示：

在这里插入图片描述

1.获取当前最大socket编号：对应/proc/pid/fd，用来查看当前进程socket最大编号；
2.获取当前最大限制数：对应/proc/pid/limits，用来查看当前进程socket最大编号限制，当最大编号超过限制数，一般需要调整限制数；
3.开始监控：对应nohup strace -t -e trace=network -f -o output.log -p 32258 -s 32 2>&1 & ，开始监控当前进程网络操作如端口绑定、解绑、连接、读、写、关闭等，此刻开始所有的网络调用将输出到output.log；
4.等待监控时间：对应Thread.sleep，表示主线程等待时间监控时间，当超过此时间将结束监控；
5.结束监控：杀掉strace进程，停止output.log写入后续网络请求，strace对性能存在一定的影响，需要杀掉。
6.汇总分析：抽取output.log中的connect日志，并根据对端服务进行汇总后倒叙输出sum.log，一般来说前几行服务是使用socket编号的大户。

目录结构

network_port_monitor.zip：实现了跟踪逻辑，支持JDK1.6+；
network_port_monitor.sh: 脚本入口；
network：此目录存放网络日志output.log、汇总日志sum.log。
在这里插入图片描述

### 操作说明

执行监控脚本后，可使用ctrl+C强制中断，此刻不确定strace还在进行中，需要使用ps -ef | grep strace 查找并关闭。

请求网络跟踪

1 . chmod +x network_port_monitor.sh
#Linux下设置执行权限

2.nohup ./network_port_monitor.sh 242772 30000 100 2>&1 &
#执行监控，其中pid 242772 为目标进程ID,30000（单位毫秒）为监控时长，100为消息体长度，长度越大性能越差。

3.tail -f nohup.out
#查看执行过程，当前最大值为/proc/pid/fd,限制值为/proc/pid/limits,当出现停止监控说明已完成任务，若输出不是如下信息，则需查询strace进程。
在这里插入图片描述

文件内容说明

output.log文件

由strace命令直接生成，每一行为一次网络方法调用，共分为四部分，如下图所示：
在这里插入图片描述

3087为线程编号，21:00:30为时间，Sendto*****=为方法调用，73为耗时，单位毫秒。这四列数据都有何用途？
线程编号：用于在线程堆栈(jstack pid)查找堆栈信息，一定能找到某个线程，如果线程执行特定业务，则可以根据线程名称就能定位到具体业务，定时任务线程一般都有特定的名称，如下图所示：
在这里插入图片描述

其中nid的值为线程十六进程，通过查找发现为BP3****任务就能找到对应的代码。如果线程执行不同的任务如web http线程,因为线程可执行所有的WEB业务，当业务种类过多，通过线程名称并不能定位业务代码，当线程执行一个长时任务时，结束监控时仍没结束时通过堆栈信息也能找到业务，不过这种可能性较低。

时间：和业务日志核对，找到业务日志的时间点日志，推导业务。

方法调用：提取相应的信息，如本服务IP、PORT、对端IP、对端PORT、消息体。可用于统计与第三方服务调用情况，本次工具就利用到了这种信息，后续在SUM文件说明，消息体用于和业务日志或代码核对。

耗时：如果发现服务卡顿，通过此字段能定位到具体那几笔操作，后与业务日志核对。
也可进行统计。

sum文件

sum文件用于明确与哪些依赖服务（可以是JAVA服务、REDIS、MQ等任何服务）交互，存在本地端口滥用问题。每一行为依赖服务消耗的端口数，文件内容按照端口数倒叙，端口数最大的在第一行，最小的在最后一行，如下图所示：

在这里插入图片描述

其中::ffff:172.27.21.26:26999为依赖服务的IP、PORT，5060为本地消耗端口数，虽说端口数可能存在整个进程中的所有线程都可复用的情况，但不影响整体结果。
sum文件的内容源于output.log中的connect方法，如下图所示：

在这里插入图片描述

17565为端口编号、2838位依赖服务PORT，::ffff:172.27.202.50为依赖服务IP。

性能分析

首先，通过多次执行监控，多次分析不同sum.log，监控时间尽可能长，保证那些有隐患的代码能够执行。对那些统计数大或增幅较快的依赖服务访问都认为是可疑的；
其次，查找依赖服务的客户端业务代码：
1.在output.log中搜索“htons(port)”，然后再比较IP是否一致，最好从尾到头搜索，因为后续还要分析业务日志、堆栈；
2.分析output.log此行socket编号后续的读写操作有特殊的字符能定位代码，否则；
3.通过线程ID在当前堆栈中查找，看是否能分析出，否则；
4.分析此时刻的业务日志，如果分析不出，则回到第1步分析下一行。
最后，使用复用http连接或socket技术优化代码。

位代码，否则；
3.通过线程ID在当前堆栈中查找，看是否能分析出，否则；
4.分析此时刻的业务日志，如果分析不出，则回到第1步分析下一行。
最后，使用复用http连接或socket技术优化代码。