性能文章>【全网首发】SSL Session默认设置导致线程阻塞了几十秒的案例分析>

【全网首发】SSL Session默认设置导致线程阻塞了几十秒的案例分析原创

299534

问题描述

几年前在做某学习APP的时候,评论服务(comment)访问评论后端服务(comment-server)正常RT在【几毫秒 ~ 几十毫秒】,偶尔(每隔几天)RT达到几十秒甚至几分钟,造成用户看不到评论列表,发表评论失败等不好的体验。

分析过程

系统交互关系

image.png

  • 网关与comment之间通讯协议是LWP(LaiWang Protocol)
  • comment与SLB之间通讯协议是https

comment调用comment-server超时?

在应用调用依赖服务的时候,会记录下【时间戳,依赖类别,调用的接口,响应时间,状态码】等指标信息。
通过监控及日志信息,出现问题的时候与SLB交互的RT是【452秒】,初步定位是【SLB】或【comment-server】处理慢导致的,所以联系了运维同学、负责【comment-server】的同学一起排查。

与SLB交互耗时

image.png
其中request_time:0.004秒,upstream_response_time:0.004秒

comment-server处理耗时

image.png
处理耗时【4毫秒】,看来锅是自己的😳。

Review代码

应用访问SLB使用的是Apache HttpClient,代码抽象表达如下:
image.png
这个代码哪里似乎有问题?

GC导致的阻塞?

通过查看GC Log,发现CMS GC耗时较长,与超时的时间点是能够对应上的,终于发现了线索。
发生CMS GC的时候,线程都在忙些什么呢?这时候LWP框架的线程dump起到了关键作用,下面对LWP简单做下介绍。

线程模型

LWP是一个RPC框架,网络通讯框架使用的是netty。
image.png

业务线程池

线程池初始化

image.png

拒绝策略

image.png
在线程blocked的时候,LWP框架打印出了当时的线程栈信息,发现所有业务线程都阻塞在了SSL交互过程中。

问题根因

SSLSessionContext’s ssl session缓存(which is a SoftReference cache) 超时时间默认是86400s (24小时),ssl session缓存大小默认是没有限制的,导致CMS GC处理SoftReference的时候耗时较长导致的。
算是JDK的一个Bug,如下:
image.png

解决办法

设置SSLContext实例的sessionCacheSize、sessionTimeout,示例:

sslContext.getClientSessionContext().setSessionCacheSize(1024);
sslContext.getClientSessionContext().setSessionTimeout(60);

不仅https,对于使用SSL通讯的应用同样需要注意上面的问题。

参考资料

点赞收藏
大禹的足迹

在阿里搬了几年砖的大龄码农,头条号:大禹的足迹

请先登录,查看3条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

关于SimpleDateFormat线程安全问题根因探究

关于SimpleDateFormat线程安全问题根因探究

记一次“雪花算法”造成的生产事故的排查记录

记一次“雪花算法”造成的生产事故的排查记录

【全网首发】记一次MySQL CPU被打满的SQL优化案例分析

【全网首发】记一次MySQL CPU被打满的SQL优化案例分析

【全网首发】记一次socket read导致业务线程阻塞的案例分析

【全网首发】记一次socket read导致业务线程阻塞的案例分析

【全网首发】一种检测线程阻塞的实现思路

【全网首发】一种检测线程阻塞的实现思路

单服务并发出票实践

单服务并发出票实践

4
3