惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园_首页
H
Help Net Security
N
Netflix TechBlog - Medium
Apple Machine Learning Research
Apple Machine Learning Research
P
Proofpoint News Feed
A
About on SuperTechFans
V
V2EX
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
宝玉的分享
宝玉的分享
aimingoo的专栏
aimingoo的专栏
F
Fortinet All Blogs
博客园 - 【当耐特】
Microsoft Security Blog
Microsoft Security Blog
Martin Fowler
Martin Fowler
I
InfoQ
Google DeepMind News
Google DeepMind News
人人都是产品经理
人人都是产品经理
Engineering at Meta
Engineering at Meta
腾讯CDC
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
B
Blog RSS Feed
U
Unit 42
The Cloudflare Blog
Y
Y Combinator Blog

博客园 - 寒魔影

Linux waitpid函数分析 不同进程内相同的变量内存地址是相同的 Linux 内存虚拟地址介绍 Sword B树学习笔记二 Sword B树学习笔记一 defined but not used警告屏蔽 apisix流量高峰期服务卡住问题 服务资源加载延迟异常增加 Linux 常用命令四 TCP全连接队列 调用writev收到信号SIGPIPE问题分析记录 epoll_wait监听事件延迟问题记录 writev发送数据失败 C++ new关键字运算符重载 Missing separate debuginfos类型崩溃分析 宏定义导致数据异常问题 服务压测偶现卡住问题分析 C语言 数据类型 Linux 终端光标控制函数
服务卡死现象分析实录
寒魔影 · 2025-05-08 · via 博客园 - 寒魔影

问题描述

今天巡检服务,发现服务经常性重启,分析k8s管理日志,发现是服务的健康检查超时导致容器被k8s杀死。

问题分析

第一步
分析:开始发现这个现象比较诧异,我的服务是事件驱动的,按道理不会出现卡死问题,后来我自己也发现了服务卡死的现象,实锤是服务自身的问题
结论:确认是服务进程卡死导致容器重启

第二步
分析:首先我需要确认卡死的位置,我通过使用 pstack 命令去查看进程卡死的函数
结论:经过耐心等待,终于发现服务卡死的函数

第三步
分析:阅读代码,尝试分析出问题所在
结论:卡死的位置是单链表for循环,初步阅读代码对这里卡死比较疑惑,我需要当时异常的堆栈信息

第四步
分析:通过使用 gdb attach ${PID} 成功定位到异常堆栈,分析堆栈上所有的数据
结论:仔细观察堆栈数据,发现数据的一些异常,例如读取的位置异常,一些状态位异常,根据这些异常再次阅读代码

第五步
分析:对照异常的数据再次分析代码,发现了逻辑上的BUG
结论:找到问题点,出版本修复该问题,验证通过

总结

本次问题分析耗时6小时左右,分析进度其实还是能够接受的,可以归纳的有以下几点
1. 使用 pstack 命令准确的抓到服务卡住的函数,极大缩小问题的范围;
2. 使用 gdb attach 命令顺利拿到堆栈信息,从而辅助代码分析;