线上故障处理
文章平均质量分 82
线上故障处理
码海拾贝2023
享受技术
展开
-
redis连接异常
指因为各种原因,程序对Redis的连接数激增,超过Redis服务器能够承受的上线,从而程序无法正常访问Redis进而引发功能异常的问题。Redis连接数问题并不常见,但是发生之后造成的Redis暂时不可用会影响正常功能,至少系统性能急剧下降,影响较大。自2020年来,贝壳线上服务出现过4次Redis连接数问题在本章节,希望能够带大家了解Redis连接数问题的现象和解法。原创 2023-03-28 19:20:37 · 1279 阅读 · 0 评论 -
Young GC过于频繁
YoungGC频繁一般是内存问题,在优化代码降低频率的同时,也需关注某个时间段的累计耗时。总的来说,在CPU Quota允许的范围内,GC总耗时越少越好,GC频率反倒不是那么重要。展开: JVM / 内存 / GC / ClassLoader这一行,找到监控面板:GC耗时 和 GC原因与频次。Young GC过于频繁,说明JVM内存分配压力大,可能是Young区比较小或者代码加载到内存的数据过多。Young GC频繁,通常不用立即处理,大多需要优化代码。可参考原因部分,优化代码,调整GC参数。原创 2023-03-28 19:28:52 · 5577 阅读 · 3 评论 -
线程池饱和异常
线程池(ThreadPoolExecutor)使用率达到100%,新提交的任务被拒绝,这种情况我们称之为线程池饱和。线程池使用率 = 活跃线程数(getActiveCount) / 最大线程数(getMaximumPoolSize),线程池饱和意味着:队列使用率100%,任务已堆积,内存占用上升所有线程已被占用,新提交的任务可能被拒绝处理,导致业务中断通过本章节,你将了解到如何监控、查看、定位线程池饱和导致的生产问题。原创 2023-03-28 09:39:25 · 1381 阅读 · 0 评论 -
物理机CPU使用率报警
SRE托管的应用开启了CGroup CPU限制,但是部分早期部署的应用,CPU无限制或限额过高,比如,40CPU的物理机,有的应用可允许使用16CPU,如果此应用的代码有性能缺陷,会消耗过多CPU,达不到资源隔离的目的。若无法避免高峰时段执行,可尝试任务分片、隔离部署,比如,薪酬月初算薪,进程CPU使用率达到40%,k8s容器部署的话,月初可临时调度薪酬进程到独享的物理机,和其他应用隔离,算薪完成了再调度回去,释放资源。总之, CPU消耗少的,可以密集部署,提升单机部署应用的个数,合理利用内存;原创 2023-03-27 19:57:18 · 1202 阅读 · 0 评论 -
cpu报警
无论是物理机或容器化部署的应用,通常使用CGroup进行资源隔离,开发可在应用大盘看到进程的CPU额度。其中,CPU Quota是进程最大可用的CPU额度,若进程CPU使用率超过额度,会被操作系统限制CPU使用,慢请求会上升。生产环境可能不同节点的内存/CPU额度不一样,可选择节点查看单台的准确额度。进程 CPU Qutoa 使用率的取值范围是 [0 , 1],最大100%,衡量的是单位时间内,进程可用的CPU额度已使用了多少,考察的是CPU够不够用,是否应该扩容了。原创 2023-03-23 21:08:28 · 1519 阅读 · 0 评论 -
老年代内存不足报警
部分DNS解析在高并发下有性能瓶颈,确保系统的DNS是可靠的,比如,k8s dns解析策略,确保是高性能的,避免无效的查询。另外,部分域名可能会启用 DNS 负载均衡,即每次解析返回的多个IP地址的顺序不同,过大的ttl会影响负载均衡效果。除了应用层的缓存外,也可尝试 JVM自身的DNS缓存 (这个是全局的),通过命令行来控制缓存过期时间, see。DNS解析失败未必会产生负面影响,比如,可能当时只有DNS健康检查,没有业务请求在执行。DNS解析通常是偶发的,开发能做的有限,可向运维反馈,持续观察。原创 2023-03-23 20:31:08 · 635 阅读 · 0 评论 -
DNS解析异常
部分DNS解析在高并发下有性能瓶颈,确保系统的DNS是可靠的,比如,k8s dns解析策略,确保是高性能的,避免无效的查询。另外,部分域名可能会启用 DNS 负载均衡,即每次解析返回的多个IP地址的顺序不同,过大的ttl会影响负载均衡效果。除了应用层的缓存外,也可尝试 JVM自身的DNS缓存 (这个是全局的),通过命令行来控制缓存过期时间, see。DNS解析失败未必会产生负面影响,比如,可能当时只有DNS健康检查,没有业务请求在执行。DNS解析通常是偶发的,开发能做的有限,可向运维反馈,持续观察。原创 2023-03-22 20:18:31 · 526 阅读 · 0 评论 -
线上问题FullGC
对CMS来说,FullGC是比较正常的,每次STW也比较短,但频繁的话会导致吞吐量下降,因此重点考察CMS FullGC的频率,目前1分钟超过12次就报警。内存分配速率越大,GC越频繁,两次 Young GC 的间隔时间尽量大于接口P99.9的时间,这样尽量让对象在 Young 区就被回收,可以减少很多停顿。若在总的Heap内存不变的情况下调大Young区,可适当调小Old区,但考虑到浮动垃圾,建议Old区大小为一轮回收后Old区活跃对象的3倍左右。尽可能保证接口内存开销的稳定性,避免浪费资源。原创 2023-03-21 19:35:16 · 240 阅读 · 0 评论