记一次线上问题定位过程

作者:神秘网友 发布时间:2021-11-25 14:06:34

记一次线上问题定位过程

  1. 出现问题,但不能快速修复

    1. 系统在高峰期突然出现了大面积的core dump,通过gdbcore文件发现,是core在发送数据到另一个服务的地方,打开堆栈对应的代码,是公司的一个基础库文件,只是简单的声明一个protobufmessage对象,但这地方一般不太可能出现core啊,不然程序到处都有类似的做法,为啥不在其他地方core了难道是服务的其他线程导致的用gdb的thread apply all bt查看各个线程堆栈,大部分线程处于sleep或者等待条件信号中(线上服务等待处理请求吧),不太像是有问题啊,这就有点无解了。
    2. gdb打开其他机器实例的core文件看看,发现线程1还是一样的堆栈信息,显示core在protobufmessage对象中。。。稍微瞄几眼protobuf声明对象的过程,无非就是申请内存,没什么值得怀疑的,如果这里有问题,服务中用到pb对象的地方很多,为什么偏偏就core在同一个地方
  2. 降级止损

    1. 百思不得其解,查查服务的日志,发现有大量的请求下游服务超时,查看这个下游服务的负载情况,发现负载很高,难道是这个下游服务导致的仔细一想,既然大量实例在同一时间core了,也会触发线上监控进程把服务重新拉起来,这样短时间内会有大量请求集中请求到下游某个服务的ip(下游服务有多个实例,但由于服务本身在数据还没准备好之前,不能向注册中心注册,不然会暴露名字给上游,所以这时候要访问下游只能通过ip来访问),所以下游服务负载高不是导致core的原因,采取了批量重启+请求降级处理。但很不幸,重启后进程服务了短暂的时间后又core了。
  3. 降级没用,继续找原因止损

    1. 看来还是得先把core的原因找出来。既然都是在线程1的同样的地方core了,这地方应该是有问题的,可以从这里入手。查看当前请求中的数据,发现不同core文件中有个字段的值是一致,这是否可以猜测是某种特殊的请求才会导致core马上打电话找产品运营人员,先把这种流量屏蔽了,10分钟过去了,发现还真的不再core了,观察了半个小时,服务正常,这时已经是凌晨4点了。。目前只能先这样止损,等第二天找出core原因。
  4. 找到潜在原因,并修复

    1. 第二天上班仔细定位问题,还是跟昨晚一样,打开core文件,查看堆栈信息,对比源代码,发现core的地方的源代码的下面几行调用了一个序列化函数,而且这个函数是个inline的,因为inline函数在编译器编译的时候,只是把内容嵌入进去,不做函数调用,所以如果在这里core了,也不会有堆栈信息。为了验证这个猜测,gdb调试core文件的时候,我故意打印当前inline函数里面的变量,确实能打印出来。。(反证:如果程序还没执行到这里就core了,不可能能打印出变量信息),所以断定是在序列化的过程core了。那就把注意力聚焦在序列化上。序列化的实现是公司2005年的代码了,到现在也有16年的时间了,不太可能会出现问题吧序列化初看很复杂,涉及到内存设计,序列化编码过程。仔细一看,大概意思就是把C++各个基础类型写入队列中,迭代器就先写元素个数,再写元素,没毛病啊继续深挖,发现了一个关键的信息:序列化字符串的时候会判断大小,如果超出一定大小,会抛异常。。。对比了这个特殊流量的某个字符串长度,确实很长,问题应该就是出在这里了。查了相关资料,查到是gcc的低版本中,如果底层有抛异常,会被捕捉后直接退出,也不打印堆栈了,后来有人上报了这个bug并在gcc8中修复了。这就难怪我看core文件一直没看出core的真正地方了。针对本次core的案例,解决办法也很简单,修改那份陈年老旧的代码(当然如果通用一点,直接hook __cxa_throw,把堆栈打印出来),至此,问题已经定位到,并找到了解决方案。
    2. 在__cxa_throw中,底层是捕捉到异常后就退出:
      1. void * execute_native_thread_routine(){
            try {
             ...   
            }catch(...){
                std::terminate();
            }
        }
        View Code
      2. core dump之后,查看core文件是这样的
  5. 方案

    1. hook__cxa_throw()让每次生成的 coredump 都带上堆栈
    2. #include iostream
      #include stdexcept
      #include thread
      
      extern "C" { //加这3行代码,通过 hook __cxa_throw,直接 abort,可以避免 stack unwind。
      void __cxa_throw(void* ex, void* info, void (*dest)(void*)) { ::abort(); }
      }
      
      void func(){
          throw std::runtime_error("die");
      }
      
      int main() {
          std::thread t(func);
          t.join();
          return 0;
      }
      View Code
    3. 效果
  6. 代码

    1. https://github.com/longbozhan/sample/tree/master/hook_exception
  7. 参考

    1. https://byronhe.com/post/cpp-throw-coredump-with-backtrace/
    2. https://abcdabcd987.com/libstdc++-bug/

本文章教程介绍完毕,更多请访问跳墙网其他文章教程!

记一次线上问题定位过程 相关文章

  1. 记一次线上服务器load高问题定位和解决

    记一次线上服务器load高问题定位和解决 1.top 查看load free空间还很大 应该不是GC导致的分析下面的进程,发现java进程占用了100%的CPU 2.查找java进程下面的哪个线程占用CPU高ps -ef|grep java 获取PID 4381 top -H -p 4381通过这个命令发现有一...

  2. 记一次线上Java程序导致服务器CPU占用率过高的问题排除过程

    记一次线上Java程序导致服务器CPU占用率过高的问题排除过程 博文转至:http://www.jianshu.com/p/3667157d63bb,转本博文的目的就是需要的时候以防忘记 1、故障现象 客服同事反馈平台系统运行缓慢,网页卡顿严重,多次重启系统后问题...

  3. 记一次线上服务CPU 100%的处理过程

    告警 正在开会,突然钉钉告警声响个不停,同时市场人员反馈客户在投诉系统登不进了,报504错误。查看钉钉上的告警信息,几台业务服务器节点全部报CPU超过告警阈值,达100%。 赶紧从会上下来,SSH登录服务器,使用 top 命令...

  4. 记一次线上事故处理过程,linux服务器磁盘空间被占满

    记一次线上事故处理过程,linux服务器磁盘空间被占满 公司采用微服务架构服务部署在docker容器,早上改完程序bug,准备更新程序,结果docker报错,错误如下图所示: 报错信息如下: open /var/lib/docker/tmp/GetImageBlob399886705: no space l...

  5. 记一次线上内存泄漏问题排查

    记一次线上内存泄漏问题排查 一 故障描述 管理后台发现部分接口长时间无响应,此问题出现多次,每次都需重启项目就可以解决。查看日志发现多次出现java.lang.OutOfMemoryError: GC overhead limit exceeded,目前项目堆大小为固定2G,后...

  6. 记一次线上CPU 100%问题

    记一次线上CPU 100%问题 记录最近收到线上服务cpu100%报警处理过程。 2.1 先恢复服务保留线程 保留1台机器,其他机器重启恢复服务 2.2 定位cpu使用率高的线程 通过top -Hp pid定位线程 2.3 定位代码 通过jstack导出线程快照,将高线程id转...

  7. 记一次线上Kafka CommitFailedException

    记一次线上Kafka CommitFailedException CommitFailedException,顾名思义就是Consumer客户端在提交位移时出现错误或异常,还是那种不可恢复的严重异常。 报错: Caused by: org.apache.kafka.clients.consumer.CommitFailedException: Commit cannot be com

  8. 记一次线上OOM故障 Java heap space

    记一次线上OOM故障 Java heap space 1、发现问题 早上测试环境一个应用机器容器 异常退出,然后开始排查问题,同时查看生产环境是否异常,发现生产程序正常运行,但是内存占用特别大,达到了70%,平时大部分时间保持在2,30%的...

  9. 记一次线上SQL索引优化及索引选择错误原理分析

    记一次线上SQL索引优化及索引选择错误原理分析 前两天同事负责的订单模块查询出现了一个奇怪的问题,当加入筛选条件后会出现查询超时的问题,查询全部订单的时候没有问题,SQL如下(数据已脱敏,使用的是MySql): SELECTa....

  10. 记一次线上DPDK-LVS的故障排查

    记一次线上DPDK-LVS的故障排查 背景 我们内部基于dpdk自研的高性能负载均衡器dpvs已经在多个机房部署上线,运行正常,但近期有多个金融相关的业务反馈,服务数据包在经过dpvs转发后,会出现hang住的情况。 问题 dpvs已经在多个...

  11. 一次线上生产问题的全面复盘 【定位-分析-解决】

    一次线上生产问题的全面复盘 【定位-分析-解决】 来自:crossoverJie 目录: 写在前面 生产现象 定位问题 解决办法 本地模拟 内存分析 总结 写在前面 之前或多或少分享过一些内存模型、对象创建之类的内容,其实大部分人看完...

  12. 记一次线上排查问题之Arthas

    记一次线上排查问题之Arthas Arthas 是阿里开源的java诊断工具。所以有直接的中文官网可以查看,很是方便。 为了让用户理解arthas能做什么,arthas官网给出了很典型的问题场景,如下: 这个类从哪个 jar 包加载的?为什么会报各...

  13. 记一次通过jprofiler定位cpu暴增的过程

    记一次通过jprofiler定位cpu暴增的过程 背景:今天线上的一个环境cpu点击几个菜单总是能快速升到99%,而且很难降下来,该环境数据量也不多,初步看有几张表也就四五百万条数据,但是页面展示分页展示的,按说不至于占用cpu...

  14. 记一次Java线上内存溢出问题排查

    记一次Java线上内存溢出问题排查 1、top下对当前服务器内存有个大致了解 top后 shift+M按照内存占用由大到小排序,RES是此进程实际占用内存,%MEM是占服务器总内存的49.8。 2、利用ps命令查看服务pid [[emailprotected] java]# ps -aux|grep jav...

  15. 一次线上OOM解决记录:GC overhead limit exceeded

    问题发现: 最近线上一个后端接口项目连续两天中午12点30分左右QPS激增,导致2台实例中的某一台由于垃圾回收问题,导致CPU占用持续偏高,触发监控系统CPU占用告警和响应时间超时告警。 现象如下: QPS瞬时激增后回落 接口非...

  16. 记一次jstack命令定位问题

    今天天气不错,但是赶上恶意加班心情就不爽,怀着不爽的心情干活,总能创造出更多的问题,这不,今天就自己挖了一个坑,自己跳进去了,好在上来了 经过是这样的,开始调试canal采集binlog时,由于添加了一个上报数量大小...

  17. 后端开发 - 记一次生产问题定位

    后端开发 - 记一次生产问题定位 后端开发 - 记一次生产问题定位 @auther 张念磊 @date 2020/7/25 文章目录 后端开发 - 记一次生产问题定位 问题描述 可能的原因 尝试解决 定位到问题 最后 补充 查看系统总线程数 查看进程下的所有线...

  18. 一次线上OOM(java.lang.OutOfMemoryError: GC overhead limit ex

    一次线上OOM(java.lang.OutOfMemoryError: GC overhead limit exceeded) 环境 16G运行内存,PostgreSql数据库 Java8默认收集器Parallel Scavenge, 即新生代 PS-Scavenge, 老年代 PS-MarkSweep(Parallel-Scavenge收集器架构中本身的老年代收集器,与Serial Ol

  19. 【工作记录】记一次问题排错和解决过程

    【工作记录】记一次问题排错和解决过程 今天下午配合前端那边联调接口,接口是用部署在服务器上的,但是这个时候,报错了,如何在服务器上排查错误,经历的少,这个过程浪费了不少的时间。所以这次记录一下,保证明...

  20. 记一次后端sql执行导致性能问题的分析过程

    记一次后端sql执行导致性能问题的分析过程 问题描述: 部门新开发了一个BI系统,刚开始操作还好,后来越用越慢,有时候点击一个菜单,展示数据列表能等上两三秒,瞬间奔溃,于是想跟踪查看下到底是什么耗时这么久。 1、...

每天更新java,php,javaScript,go,python,nodejs,vue,android,mysql等相关技术教程,教程由网友分享而来,欢迎大家分享IT技术教程到本站,帮助自己同时也帮助他人!

Copyright 2021, All Rights Reserved. Powered by 跳墙网(www.tqwba.com)|网站地图|关键词