线程池相关故障梳理总结

下面贴一些典型的常见 Case,开发同学基本一看就懂并不神奇。

数据库相关

热更新

在事务里热更新同一条数据容易引发锁等待造成慢 SQL,常见于一些 update count,update quota 类的业务场景。

  • 故障案例1:某次压测对 DB 产生瞬时 60w+ QPS 的压力,期间同一条数据(更新 count 字段)在事务里大量热点更新导致了行锁争抢产生慢 SQL。

  • 故障案例2:几个大用户高并发操作,其中涉及单条热点数据在事务里的更新,排查发现单次更新耗时高达5-6秒,积压的线程引起 Dubbo 对外服务线程池堆积,最终线程池满导致无法对外服务。

    • 线下模拟测试发现 1200 并发进行热点数据的更新(在特定的数据库版本和配置下),开启事务需要1分钟,不开启事务需要3秒。

大表加字段

DDL 变更有多种方式,最原始的方式会造成锁表问题进而引发大量相关联 SQL 锁等待产生慢 SQL;DDL 变更建议走 Online DDL。历史上出现过的一些锁表的 Case 应该是没有走 Online DDL,也可能当时数据库版本不支持 Online DDL。

  • 故障案例:大表添加字段未采用 Online DDL,在最后阶段会对表加 Metadata Lock 原子锁,使得大量相关 SQL 锁等待产生慢 SQL,进而快速打满应用线程池。

索引没走对(走了主键全表扫描)

常见于 order by id limit 场景,就算 where 条件里的字段有索引还是有可能走全表扫描。可以通过 IGNORE INDEX(PRIMARY),FORCE INDEX(idx_xxx) 等方式来解决。

  • 故障案例:凌晨 3 点多突然收到报警数据库 CPU 100%,排查发现某查询 SQL 走了主键索引触发了全表扫描(SQL 样例为:where a= and b= and c= and d= order by id desc limit 20,当时只有 idx_a_b_e 的联合索引),期间在数据库运维平台手工无差别限流 SQL 有所缓解但很快 CPU 又会飚上来,也尝试了物理删除一些无效数据减少数据量,多管齐下,最后通过临时增加一个 idx_a_b_c_d 新的全字段覆盖的索引止血。

深分页

数据量大时深分页引发慢 SQL 也是个常见的经典问题。解法可以是使用 NexToken 或者叫游标的方式查询,目前阿里云有很多 OpenAPI 已经提供了 NextToken 的查询方式。

  • 故障案例:某账号(数据量巨大)调用某查询接口分页查询引发慢 SQL 导致数据库连接池满进而导致 Dubbo 线程池满无法对外服务,紧急限流该账号对该接口的调用后恢复。

调用量大

故障案例1:故障恢复后,短时间重试待处理任务到单机执行,量太大导致单机线程池满导致服务受损。

  • 解法:系统层面需要做一定的限流策略,单机任务瓶颈时应切换到网格型任务。

故障案例2:压测未预热,直接一次性并发到压测值导致线程池满,导致数据库有很多事务等待的慢 SQL。

  • 解法:压测应按照一定节奏逐步上量,观察系统负载并及时暂定,而不是开局就决战。

其他

故障案例:查询没加 Limit 导致应用 Full GC

  • 该 Case 不涉及线程池满问题,但笔者觉得有一定的代表性因此也分享下。不管是查询还是删除还是更新数据,不管是代码还是日常的 SQL 订正,建议都增加 Limit 来兜底保护自己,缩小影响面。

技术视角

线程池类的故障,一般都是某个地方慢了堵了,从技术角度大多是:

1、远程调用 IO 慢导致耗时增加;

2、计算密集型应用 CPU 飙升导致耗时增加;

3、自定义业务线程池满造成排队等待导致耗时增加;

其中 2 不算常见,笔者也遇到过,发生于某 CPU 密集运算的应用系统,突增的高并发请求引起 CPU 100%;其中 1 比较常见,一般远程调用有:Dubbo、Http、DB、Redis,这些实践中都会使用连接池来与远程服务交互,凡是连接池都是有共性的,有两个需要关注的点:

  • 1、尽量减少远程调用本身的 超时时间 以实现 fast-fail 快速失败。一般是设置 ConnectionTimeout 即握手时间 和 SocketTimeout 即业务执行超时时间。

  • 2、在连接池满了以后,获取新的连接的 超时时间 也需要设置的小一些以实现 fast-fail 快速失败,这个是很容易忽略的一个点。如 Druid 里设置 MaxWait,Http 连接池里设置 ConnectionRequestTimeout。

下面列一下各个连接池需要关注的点。

Dubbo 线程池

1、线程池做好隔离,避免互相影响

  • 如内部运维接口和对外服务的接口做隔离。

  • 对外服务里核心接口和非核心接口做隔离。

2、Dubbo consumer 侧设置 timeout,根据 fast-fail 理念设置的越小越好;provider 侧的 timeout 仅仅是起到声明的效果供 consumer 参考,无实际超时杀线程的作用。

Http 连接池

1、设置 ConnectTimeout、SocketTimeout、ConnectionRequestTimeout

  • 故障案例:某次发布的代码引入了一个 SDK,该 SDK 集成了 HttpClient,但并没有设置 ConnectionTimeout,在某次网络抖动发生时,Http 连接池被迅速打满,进而导致业务线程池满导致服务受损。

2、DefaultMaxPerRoute 太小也容易导致阻塞。

  • 故障案例:某 SDK 默认设置的 128,在某次压测中发现客户端耗时较高,但服务端耗时并无波动,排查后怀疑是 DefaultMaxPerRoute 太小导致的阻塞,调大后问题解决。

数据库连接池 Druid

1、设置 ConnectTimeout、SocketTimeout。

  • 故障案例:凌晨 1 点多收到 API 成功率降低报警,排查发现部分 SQL 执行超时,原因是数据库发生了主备切换,进一步排查发现应用侧对数据库连接池没有设置 SocketTimeout 导致切换前的老的连接不会被超时 Kill 导致相关 SQL 执行超时,直到 900秒系统默认超时后才会断开连接再次重连。

2、设置 TransactionTimeout 即事务超时时间,事务就是一把锁,超时时间越长锁越久,导致不在事务里的相关 SQL 锁等待导致性能差。

  • 故障案例:在某次变更时由于代码有 bug 导致事务未提交,同时由于事务没设置超时时间,导致大量相关 SQL 超时服务受损。

3、设置 Ibatis 的 defaultStatementTimeout、queryTimeout。

4、设置 MaxWait:获取新连接的等待超时时间。

  • 小插曲:之前 Druid 默认设置的 60 秒,后来笔者与作者有过沟通反馈这个默认值太长容易坑大家,后来发现已经改为了 6 秒[1]

自定义线程池

1、线程池设置的队列过长容易造成阻塞影响吞吐。

2、future.get,默认没有超时时间,需显式传入。

  • 故障案例:Dubbo 线程池满报警,排查后发现是业务代码里使用了 future.get 没有设置超时时间,同时线程池的拒绝策略设置的是 DiscardPolicy,会导致在线程池满后新的任务被丢弃时 future.get 阻塞,进而导致 Dubbo 线程池满服务受损。

Redis连接池

1、设置 Jedis pool MaxWait,与 Druid 的 MaxWait 类似,也与 Http 连接池的 ConnectionRequestTimeout 类似。

2、设置 ConnectionTimeout、SocketTimeout,与 Druid/Http 连接池的类似。

总结

fast-fail 理念

1、本质上是不浪费系统资源,一些超时时间设置过长其实是在做无效的 IO 等待。

2、有一些个人的经验值贴一下:ConnectionTimeout 建议1-3 秒最佳,最大不超过 5 秒。SocketTimeout 根据业务请求时间情况设置建议最大不超过 10 秒,MaxWait/ConnectionTimeout 建议 3~5 秒,最大不超过 6 秒。

保护好自己:流控/背压

1、数据库后台运维平台设置自动限流,紧急情况下收到预警后第一时间手动执行限流。

2、实现 单机维度、集群维度(Region/AZ)、用户维度、接口维度 流控。

3、消息中间件拉取消息的 Client 实现背压机制。

谨慎重试

Retry 会加速系统雪崩,AWS 有一篇博客介绍了相关的经验,Link> [2]。核心要点如下:

  • 不在最上层自动重试,在单个节点里重试

  • 令牌桶控制重试的速率

  • 定时、周期性的作业需要打散,分散高峰。这块我们也遇到过类似的故障案例:

    • 故障案例1:某客户端曾经出过一个类似故障:客户端的定时心跳同一秒发送到服务端,导致服务端扛不住,此类情况需适当打散。

    • 故障案例2:某系统大量定时任务都是整点执行,一瞬间对系统压力过大引发线上问题,定时任务的周期需适当打散。

最后,本文有很多血淋淋的教训,大多是常见问题,本文肯定有不全面的地方,欢迎评论区多多指教。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/pingmian/14259.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

服务高峰期gc,导致服务不可用

随着应用程序的复杂性和负载的不断增加,对JVM进行调优,也是保障系统稳定性的一个重要方向。 需要注意,调优并非首选方案,一般来说解决性能问题还是要从应用程序本身入手(业务日志,慢请求等)&am…

struct.unpack_from()学习笔记

struct.unpack_from(fmt,b_data,offset) 按照指定的格式fmt,从偏移位置offset,对b_data开始解包,返回数据格式是一个元组(v1,v2…) fmt可以有: _struct.py: The remaining chars indicate types of args and must match exactly;…

基于Vue的验证码实现

一、验证码核心实现 创建slide-verify.vue&#xff0c;代码如下&#xff1a; <template><divclass"slide-verify":style"{ width: w px }"id"slideVerify"onselectstart"return false;"><!-- 图片加载遮蔽罩 -->&…

网络编程 —— Http设置请求头

概念 请求报文: 在发送请求时候&#xff0c;把数据封装成一个包&#xff0c;这个包就是请求报文&#xff0c; 请求头: 键值对&#xff0c;发请求需要配置的信息&#xff0c;例如请求长度的配置 请求行: 请求方式路径 请求协议的版本 如果每个请求都需要把通信证token…

java项目之图书管理系统源码(springboot+vue+mysql)

风定落花生&#xff0c;歌声逐流水&#xff0c;大家好我是风歌&#xff0c;混迹在java圈的辛苦码农。今天要和大家聊的是一款基于springboot的图书管理系统。项目源码以及部署相关请联系风歌&#xff0c;文末附上联系信息 。 项目简介&#xff1a; 系统主要分为管理员角色和用…

水果成篮-力扣

这道题目一开始的思路是利用水果的种类大于等于三&#xff0c;来作为滑动窗口的维护条件&#xff0c;使用两个key值来记录两种水果的值&#xff0c;当遇到第三种水果时&#xff0c;则将slowindex设置为slowindex-1&#xff0c;然后将slowindex逐渐缩小&#xff0c;来查找前x个相…

【Redis7】Redis持久化机制之RDB

文章目录 1.RDB简介2.RDB配置触发设置3.RDB的优缺点4.如何检查修复RDB文件5.如何禁用RDB6.RDB参数优化7.总结 1.RDB简介 Redis持久化机制中的RDB&#xff08;Redis Database&#xff09;是一种将Redis在某个时间点的数据以快照形式保存到磁盘上的方法。 原理&#xff1a;RDB通…

Node.js版本管理与npm镜像源管理

一、nvm —— node的版本管理工具 1.安装 nvm Windows 使用 nvm-windows点击跳转下载网站。 按照图示操作步骤下一步即可&#xff0c;对于下载位置推荐不要C盘任意即可 2.查看可用的 Node.js 版本&#xff1a; nvm list available #显示所有可以下载的版本3.安装特定的…

自动化证书管理|如何通过可管理的ACME为“90天SSL证书”做好准备?

SSL证书在保护组织的Web通信安全方面发挥着至关重要的作用。最近的趋势表明&#xff0c;在增强安全性诉求的推动下&#xff0c;SSL证书有效期逐渐缩短。这一变化需要组织耗费更多的时间和资源来进行证书更新工作&#xff0c;为了降低潜在风险并简化流程&#xff0c;自动化证书管…

windows、mac、linux中node版本的切换(nvm管理工具),解决项目兼容问题 node版本管理、国内npm源镜像切换

文章目录 在工作中&#xff0c;我们可能同时在进行2个或者多个不同的项目开发&#xff0c;每个项目的需求不同&#xff0c;进而不同项目必须依赖不同版本的NodeJS运行环境&#xff0c;这种情况下&#xff0c;对于维护多个版本的node将会是一件非常麻烦的事情&#xff0c;nvm就是…

python查找内容在文件中的第几行(利用了滑动窗口)

def find_multiline_content(file_path, multiline_content):with open(file_path, r) as file:# 文件内容file_lines file.readlines()# 待检测内容multiline_lines multiline_content.strip().split(\n)# 待检测内容总行数num_multiline_lines len(multiline_lines)matchi…

安装测缝计安装事项详解

在建筑和工程领域&#xff0c;测量缝隙和裂缝的准确性对于工程质量和安全性至关重要。测缝计作为一种专业的测量工具&#xff0c;能够帮助工程师和施工人员准确测量和监测建筑结构的缝隙情况&#xff0c;进而采取合适的修复和加固措施&#xff0c;保证建筑物的稳定性和安全性。…

Vs Code插件位置:

Vs Code插件位置&#xff1a; C:\Users\dell.vscode\extensions

PCIe协议之-Flow Control基础

✨前言&#xff1a; Flow Control即流量控制&#xff0c;这一概念起源于网络通信中。PCIe总线采用Flow Control的目的是&#xff0c;保证发送端的PCIe设备永远不会发送接收端的PCIe设备不能接收的TLP&#xff08;事务层包&#xff09;。也就是说&#xff0c;发送端在发送前可以…

Flat Ads获广东电视台报道!CEO林啸:助力更多企业实现业务全球化增长

近日,在广州举行的第四届全球产品与增长展会(PAGC2024)上,Flat Ads凭借其卓越的一站式全球化营销和创新的变现方案大放异彩,不仅吸引了众多业界目光,同时也在展会上斩获了备受瞩目的“金帆奖”,展现了其在全球化营销推广领域的卓越实力和专业服务。 在大会现场,Flat Ads的CEO林…

XMR交易所对接方案

交易所对接 XMR 充币 用户充币地址生成 使用 subaddress 即可 充币数据监测 monero-wallet-rpc 的API文档: https://web.getmonero.org/resources/developer-guides/wallet-rpc.html 步骤1 : 使用 monero-wallet-cli 的以下选项生成 incoming-only钱包: --generate-from-v…

# 全面解剖 消息中间件 RocketMQ-(2)

全面解剖 消息中间件 RocketMQ-&#xff08;2&#xff09; 一、RocketMQ – RocketMQ 各角色介绍 1、RocketMQ 各角色介绍 Producer : 消息的发送者; 举例:发信者。Consumer : 消息接收者; 举例:收信者。Broker : 暂存和传输消息; 举例:邮局。NameServer : 管理 Broker; 举例…

css动画之hamburgers

动效1 代码如下&#xff1a; <!DOCTYPE html> <html><head><meta charset"utf-8"><title></title></head><body><div><label class"hamburger"><input type"checkbox"><…

BGP选路规则实验

实验拓扑及要求如下 注意&#xff1a; 在完成要求时&#xff0c;默认区域内IGP搭建完成&#xff0c;IBGP和EBGP的对等体关系建立完成 结果演示如下 IBGP内部搭建&#xff1a;使用OSPF IBGP与EBGP对等体建立 要求一&#xff1a;PreVal策略 PV属性默认值为0&#xff0c;规则是…

2024年ai知识库:特点、应用与搭建

随着科技的进步和企业的需要&#xff0c;ai知识库逐渐走进大众的视野并深受企业的青睐&#xff0c;掀起了搭建ai知识库的热潮。LookLook同学就来简单介绍一下关于ai知识库的特点、应用与发展趋势&#xff0c;带你了解2024年的ai知识库。 一、ai知识库的定义与特点 ai知识库是结…