经常在线上看到一些应用直接因为连接池无法获得连接, 导致整个应用不在响应任何请求. 常见的有数据库连接池连接泄漏, Http 连接池泄漏. 对于这种连接泄漏的问题, 一般是应用没有考虑到某些特殊情况, 特殊异常的处理导致不能用完之后返回连接到连接池. 这里就针对 Apache HttpClient 连接池泄漏这种清楚, 分析一下基本的求解思路.

- 阅读剩余部分 -

异步 IO 的使用, 使得线程不再 block 在 IO 上面, 可以做更多的事情, 所以 Java 的 NIO 在很多地方都使用起来了. 同时由于微服务的广泛普及, 企业内部各种服务直接的相互调用更多了. 之前很多都是使用 Apache 社区的 HttpClient 来相互调用, 如今更多的代码转向了 HttpAsyncClient. 这里就记录一个由于 HttpAsyncClient 的错误使用引起的内存泄漏的案例.

- 阅读剩余部分 -

1. 使用 lsmod 命令查看已经load 的内核模块, 它其实读取的是 /proc/modules 的信息
2. 当系统需要某个内核模块的功能的时候, 如果该模块还么有加载, 作为 daemon 的 kmod 进程就会使用 modprobe 命令去加载该模块;
3. modprobe 可以接受模块的名称, 如: softdog, 或者该模块的别名, 如: char-major-10-30. 标准名称和别名的映射在文件 /etc/modprobe.conf 中, 如: alias char-major-10-30 softdog;
4. 模块的依赖关系在 /lib/modules/version/modules.dep 中;
5. depmod 会创建新的依赖关系;

以上内容可能过时, 来源: https://tldp.org/LDP/lkmpg/2.6/html/x44.html

1. Kernel Probes: https://www.kernel.org/doc/Documentation/kprobes.txt#:~:text=Kprobes%20enables%20you%20to%20dynamically,when%20the%20breakpoint%20is%20hit.
2. Uprobe: https://www.kernel.org/doc/Documentation/trace/uprobetracer.txt
3. https://kernelnewbies.org/Linux_3.5#Uprobes:_userspace_probes
4. https://lwn.net/Articles/499190/
5. static tracepoint and how it works: https://www.kernel.org/doc/Documentation/trace/tracepoints.txt

在 eBay, 对于线上应用的监控指标, 有个非常重要的报警数据就是 Connection Stacking alerts. 它是指某个应用的处理能力不足, 导致进来的连接(Connection)都堆积到应用前面的 Load Balancer 上. 其实监控的是 LB 上面的连接数是不是比平时多了很多, 如果多了很多, 那么就显示在这个报警仪表盘上.

什么情况下会发生 Connection Stacking? 通常有2种情况会发生 Connection Stacking: 1). 来访流量确实突然多了; 2). 进来流量还是跟往常一样, 该应用的处理能力变差了.

对于第一种情况, 也有2种细分: 一种是流量确实增多, 可是业务的平均处理时间几乎没啥变化, 或者还在合理范围内, 那么可以不去管它; 另外一种是流量的增加导致业务的平均处理时间变长, 应用的处理能力变弱, 这会导致各种预想不到的后果, 如用户在页面超时, 增加来自上游的 retry(retry storm), 或者导致该应用最终垮掉(当然这里会有各种自动扩容).

对于第二种情况, 在流量不变的情况下, 应用的处理能力变弱, 可能有各种因素. 不过我们还是大致可以分为三类. 1) 应用本身的问题导致处理变慢, 比如某些线程死锁, 导致正常处理业务的线程减少; 比如内存泄漏, 导致可用的内存减少, Java GC 时间增加; 比如缓存大量没命中; 比如业务根据用户的输入, 需要处理大量的正则表达式计算 等; 2) 依赖的其它下游其它应用服务导致本应用的变慢. 微服务的广泛使用, 一个中间层的应用通常要访问几个甚至十几个下游其它服务, 如果某个服务变慢, 同时设置的 timeout 时间或者 retry 次数不合理, 基本会导致从该服务到用户端的连锁变慢; 3) 依赖的数据库服务变慢. 数据库的种类不断增加, 企业应用使用的数据库的场景也逐渐增多. 数据库的 session 数量不够, 或者在处理大规模批处理, 或者数据库其它操作导致的锁, 都会导致访问数据库变慢.

如果要解决 Connection Stacking 问题, 就要分清当前是那种情况, 辨证施治. 对于上面提到的很多数据, 我们都有监控指标, 很容易的辨别出是那种问题, 比如: 进来请求的数据能分清是不是流量增加, 机器级别对于数据库访问的数据指标能分清是不是数据库变慢, 对于各种下游 service 调用的监控指标能反映是不是下游应用变慢;

今天要考虑的问题是针对上面第二种情况的第二种子情况: 即由下游应用变慢导致的本应用变慢. 如果我们不看各种基于微服务客户端的指标, 比如 Hystrix 暴露的指标, 有没有基于操作系统的数据能反映这种情况?

既然是下游调用, 基本是网络调用, 那么就是走网络连接, 绝大多数都是 TCP 不是 UDP, 另外一般的对于下游的服务, 我们都是使用443 或者 80 端口. 那么根据这些约束条件, 能找出某些基于 TCP 连接的数据, 能帮我诊断类似的问题吗?

在各种 Linux 的网络命令当中 ss 是一个比较好的反映网络连接的命令, 让我们看看下面这个 ss 命令的输出:

myhost:~$ ss -it '( dport = :443 or dport = :80 )'
State      Recv-Q Send-Q    Local Address:Port   Peer Address:Port                                                             
ESTAB      0      0         10.33.133.212:47314    10.33.119.204:http                                                       
     bbr wscale:8,2 rto:204 rtt:3.944/4.558 ato:40 mss:1460 cwnd:142 bytes_acked:1605128 bytes_received:1616022 segs_out:2857 segs_in:2977 send 420.5Mbps lastsnd:74840 lastrcv:74832 lastack:74832 pacing_rate 1946.1Mbps retrans:0/8 rcv_rtt:1903.35 rcv_space:96431
ESTAB      0      0         10.33.133.212:59648    10.166.224.89:https                                                          
     bbr wscale:8,7 rto:204 rtt:0.151/0.022 ato:40 mss:1460 cwnd:143 bytes_acked:832208 bytes_received:253799 segs_out:784 segs_in:610 send 11061.2Mbps lastsnd:32 lastrcv:28 lastack:28 pacing_rate 1437.4Mbps rcv_rtt:1924.95 rcv_space:37969

使用 ss 的 -i 选项, 可是使我们看到更多关于连接的详细信息, 这里我们关心的有:
lastsnd, lastrcv, lastack,
-- 未完待续