应用程序卡死如何排查

一.应用程序卡死如何排查
故障：客服报障，平台点击界面菜单无反应
排查步骤：
1.首先先从公司架构入手，2个节点2层代理负载再到后端web，程序再调用中间件，最后才到数据库
2.先把负载卸掉，用单节点单负载进行访问
3.如果不行，再连接数据库服务器，用top跟iostat命令查看系统cpu.内存跟io，看看是不是由于MySQL的配置不优化，导致系统资源耗尽，导致应用崩溃
4.如果cpu.内存，磁盘IO正常，查看MySQL的错误日志以及慢查询日志，看看有没有特殊的报错信息跟大量的慢查询sql语句，然后用explain进行分析是不是大量sql没有索引，引起全表扫描
5.进入数据库，用show processlist查看正在执行的语句，看看有没有特殊的信息。比如出现大量的锁表语句，我这边就是查到数据库出现大量的锁表语句出现，说大量的写跟读都是再同一张表上一边没进行完另一边还在请求等待就造成死锁，这是什么导致的呢，再联系中间件跟数据库关系，好像是配置中间件的读写分离规则配的有问题:主写，主从都可以读,后来中间件改成主只能写，从只能读，重启数据库，然后重启中间件，程序恢复正常

以上是个人排查思路，不同意见可以提，请勿喷！

原文地址：http://blog.51cto.com/8999a/2103440

时间： 2024-08-29 23:41:24

应用程序卡死如何排查的相关文章

Runtime.getRuntime.exec()执行linux脚本导致程序卡死有关问题

Runtime.getRuntime.exec()执行linux脚本导致程序卡死问题问题: 在Java程序中,通过Runtime.getRuntime().exec()执行一个Linux脚本导致程序被挂住,而在终端上直接执行这个脚本则没有任何问题.原因: 先来看Java代码: public final static void process1(String[] cmdarray) {        Process p = null;        BufferedReader br = null

XP下切换输入法造成程序卡死的原因及解决方案

http://blog.csdn.net/ysai/article/details/7468961 XP下切换输入法造成程序卡死的原因及解决方案 (by ysai) 现象: 在XP下,如果线程中创建了窗口而线程中没有消息循环,那么可能切换输入法时会造成程序卡死(某些XP下必现,跟安装盘有关) 原因: 线程创建一个窗口后,系统会自动创建一个Default IME窗口以便通知输入法消息(可能只有可以接收输入的窗口才会创建,未证实) XP下切换输入法,会向所有DefaultIME窗口SendMessa

一起空指针引发的程序问题的排查过程

      [文章摘要] 在C程序中,指针操作是难点和精华所在.指针一旦使用不当,极有可能造成程序的崩溃. 本文对一空指针引发的程序问题的排查过程进行了详细的介绍,为相关软件问题的分析及解决提供了有益的参考. 一.问题描述 最近,某程序在测试过程中突然崩溃.日志中出现如下内容: #0  0xf64f2b3a in FunctionA(event=666,dlgindex=0, ucErrNo=1 '\001') at src/A.c:6838 #1  0xf64e3a4f in Function

Delphi主线程重入而导致程序卡死的解决方案

Delphi的线程可以通过调用AThread.Synchronize(AProc),可以将Proc放入主线程中同步运行,此时AThread将挂起,直到主线程执行完AProc. 如果有BThread,调用了BThread.Synchronize(BProc),而BProc中释放了AThread procedure TBThread.BProc begin AThread.Terminate; AThread.WaitFor; AThread.Free; end; 此时我们的程序将会卡死,下面的代码

一次程序bug的排查

这周准备下一个QA测试的版本,把版本发到测试环境就开始发现各种问题,修修补补搞了一周,总算告一段落了. 分析一下几个bug的问题,都集中在程序模块的整合中.一个模块的一个小的修改,造成另一个模块的连锁反应.这种bug在排查的时候非常花时间,因为往往程序出错和报错的地方并不是程序真正错的地方,对着本来就没有问题的代码一遍一遍的看是看不出来问题的.这次我们最后解决问题,用了一个笨办法.我们把从上一个版本到现在的有关的commit都看了一遍,最后在一个很不起眼的地方找到了问题. 在retro过程中,和

C#中多线程写DataGridView出现滚动条导致程序卡死（无响应）的解决办法

因为写的程序涉及到多线程维护一个DataGridView,然后蛋疼的发现经常卡死...一开始以为是读写冲突的原因,然后就加了锁,问题依旧...然后发现每次出现滚动条的时候程序才会无响应,所以感觉应该是滚动条出现问题... 网上说用Invoke就可以解决问题,试了一下,可能是我使用的方法不对,还是没有解决问题-_-|| 最后使用InvokeRequired解决的... 因为我的修改DataGridView的代码是写在窗体里面的,so... private static object obj = n

程序的bug排查流程总结

只要是人写的程序,不可能没有bug,那么解决bug,将伴随程序员的一生: ? 只会写代码,但不会排查bug的程序员,只能算是业余程序员 ? 能解决一般bug的,只能算是初级程序员 ? 代码写的质量较好,还能查找较难bug的,中级程序员 ? 代码写的质量好,注重性能,不但能排查疑难bug的,还能解决疑难bug的,高级程序员 ? 代码写的质量好,注重性能,稳定性,可靠性,架构设计合理,能解决绝大部分疑难问题,属于资深程序员 以上的话引自某个论坛网站,不一定说的绝对正确,但基本是有道理的. 面对出现的

CentOS7中df命令卡死故障排查

系统信息 CentOS Linux release 7.2.1511 (Core) 故障排查过程 使用strace df命令对进程进行追踪,结果如下: ... stat("/sys/fs/cgroup/cpu,cpuacct", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 stat("/sys/fs/cgroup/blkio", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 sta

记一个程序oom的排查过程

一,背景 收到应用服务报警,然后登录上服务器查看原因,发现进程不再了. 二,问题分析 1,那么判断进程被干掉的原因如下: (1),机器重启了 通过uptime看机器并未重启 (2),程序有bug自动退出了 通过查询程序的error log,并未发现异常 (3),被别人干掉了 由于程序比较消耗内存,故猜想是不是oom了,被系统给干掉了.所以查messages日志,发现的确是oom了: Jul 27 13:29:54 kernel: Out of memory: Kill process 17982