首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    一个ext4的Bug分析过程

    某客户反映他们的实例有一段时间内慢查询突增,监控页面上也显示那段时间内监控数据也没有上报,经查看系统日志,以下内容引起了我们的注意: Mar 15 23:06:30 TENCENT64 kernel: BUG...[jbd2/md0-8:3661] ......Mar 15 23:06:30 TENCENT64 kernel: CPU: 2 PID: 3661 Comm: jbd2/md0-8 Not tainted 3.10.104-1-tlinux2-0041...所以,根据结合系统日志给出的信息,我们可以判断出,jbd2这一日志进程的callstack上的ext4_es_lru_add函数中使用的自旋锁持有时间过长导致了soft lockup这一问题。 2....总结 本文通过对Linux ext4文件系统的一个bug进行分析,探讨了ext4的延迟分配机制、块查找过程及extent cache收缩机制,并简要介绍了社区对这一个bug的修复方案。

    4.1K20

    Bug哪家强?谷歌:Linux,比我都修得好

    博雯 发自 凹非寺 量子位 | 公众号 QbitAI 过去三年内,谁家程序员修Bug最强? Linux。 谷歌如是说。...因为在他们最新发布的安全漏洞修复报告中,Linux修一个Bug平均只要15天,所用时间最少: (甚至比谷歌自家都要快) 上述数据来源于谷歌在2014年开展的零计划(Project Zero)项目,由谷歌内部的顶级安全大佬参与...这次报告的时间从2019年到2021年,整体来看,各大厂程序员在修Bug上是越来越娴熟了: 在3年前,平均三个月才能修完,还会有各种超过最后期限的拖延,到2021年就仅需52天,全年总共只有一个Bug超过了修复期限...从这一维度来看,大多数都能在104天内完成绝大多数Bug(90%以上)的修复,其中Oracle展现出了非常明显的拖延症,即有超过一半(57%)的Bug都是在deadline之后修的: 不过,人家的Bug...数也是最少的,总共只有7个…… Bug的平均修复时间也就是我们开头放出的那张表,整体上大家的Bug都越修越快,Linux新的一年更是平均半个月(15天)就能修复。

    76820

    IO告警分析思路

    写请求总数,读/写所花费的时间,以及当前正在处理的I/O总数(inprogress IO),等待I/O完成所花费的毫秒数(milli spent IO),这个是整个系统的IO统计信息 说一下合并读和合并写,linux...在读写磁盘时,为了提高性能,内核合并对磁盘相邻区域的请求,这样减少了对磁盘IO的操作,从而一定程度上提高linux性能 从上面的信息,我们已经可以定位是写磁盘造成的IO等待,接着我们需要定位是哪块磁盘造成的...从iostat中能更直观的看到那个磁盘在进行大量的读写操作,如果用-x参数,能看到更多的统计信息 sar 除了上面的工具,sar也是linux下性能分析常用的工具,sar也比较通用,除了CPU、内存之外...上面的工具,我们需要自己去分析,去查找,iotop很直观的,按照I/O统计展示进程,在运维定位IO故障中效率更高,不过,默认系统不自带,需要yum安装 此次I/O升高是由于jbd2引起的,jbd2是一个文件系统的日志功能...网上不少文章有关于jbd2引起I/O高的分析,认为比较好的是这篇https://cloud.tencent.com/developer/article/1465600,有兴趣的可以看下,里面有多种解决方案

    1.5K40

    Bug之路-串包Bug

    Bug之路-串包Bug 笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分,所以经常被唤去解决一些网络IO方面的Bug。...串包Bug现场 前置故障Redis超时 由于某个系统大量的hget、hset操作将Redis拖垮,通过监控发现Redis的CPU和IO有大量的尖刺,CPU示意图下图所示: ?...Bug复盘 此次Bug是由Redis本身Server负载太高超时引起的。Bug的现象是通过Jedis去取对应的Key值,得不到预期的结果,简而言之包乱了,串包了。...缩小Bug范围 首先:Redis是全球久经考验的系统,这样的串包不应该是Redis的问题。 第二:Redis刷新了key后Bug依然存在,而业务系统重启了之后Okay。...Bug推理 笔者意识到,之所以串包可能是由于jedisClient里面可能有残余的数据,导致读取的时候读取到此数据,从而造成串包的现象。

    1.4K10

    bug 排查大曝光,涉及Linux 内核的那种

    那些编程高手除了写代码很厉害之外,调试代码找 bug 更是手到擒来。...编写代码只是程序员的工作之一,调试代码的时间甚至会超过编写代码,之前为大家讲解了很多关于系统、架构、编程等方面的内容,这篇文章就为大家全方位展示一次涉及到内核的 bug 排查过程。...根据内核源码查系统调用 要知道这个数字的含义,我们就需要参考内核代码了,一般在 Linux 系统中必要的内核头文件位于/usr/include目录,在博主 64 位 Linux 机器上,我找到了这个文件...总结 本文为大家完整展示了一次 bug 的定位过程,可以看到 Linux 为我们提供了极为丰富的调试工具,当然这离不开 Linux 系统本身优秀的设计思想,那就是将进程和内核的运行时信息通过文件系统提供出来...希望本文对大家理解 Linux 系统下问题 debug 有所帮助。

    1.7K20

    Bug之路-串包Bug

    笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分,所以经常被唤去解决一些网络IO方面的Bug。现在就挑一个案例出来,写出分析思路,以飨读者,希望读者在以后的工作中能够少踩点坑。...串包Bug现场 前置故障Redis超时 由于某个系统大量的hget、hset操作将Redis拖垮,通过监控发现Redis的CPU和IO有大量的尖刺,CPU示意图下图所示: CPU达到了100%,导致很多...Bug复盘 此次Bug是由Redis本身Server负载太高超时引起的。Bug的现象是通过Jedis去取对应的Key值,得不到预期的结果,简而言之包乱了,串包了。...缩小Bug范围 首先:Redis是全球久经考验的系统,这样的串包不应该是Redis的问题。 第二:Redis刷新了key后Bug依然存在,而业务系统重启了之后Okay。...Bug推理 笔者意识到,之所以串包可能是由于jedisClient里面可能有残余的数据,导致读取的时候读取到此数据,从而造成串包的现象。

    73510

    得物SRE K8s 故障诊断:从 CPU 高负载到挂载泄露根源揭示

    通过在主机上运行top命令,我们可以发现尽管单机负载在合理范围内,但是单机的进程数量存在过大的情况,48个vCPU单机运行的进程总量有20155个(Linux内核中一般称作Task任务),运行中的进程仅有...通过查询资料,确认了“[jbd2/vdx-y]”格式中的jbd2代表的是:Journaling Block Device2,jbd2是Ext4文件系统中实现日志文件系统的组件,其工作原理是通过记录对文件系统所做的更改来提高数据的完整性和恢复能力...$ ps aux|grep '\['|wc -l # 内核线程总量 19798 $ ps aux|grep '\[jbd2'|wc -l # 内核线程以 jbd2 开头的总量 12769 $...以设备vdfiw为例: jbd2/vdfiw-8是一个与jbd2(Journaling Block Device version 2)内核文件操作日志系统存储的的内核线程; jbd2-ckpt/vdfiw...六、总结 至此这个问题根因总算水落石出,验证方式也得到了确认,问题的触发会有几个条件同时作用: 日志采集单机容器实例挂载了Linux系统根目录,主机挂载记录全部传递到日志采集单机的容器实例中; 运行的服务使用

    19410
    领券