本篇内容介绍了“架构出错时如何进行查询”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
创新互联秉承专业、诚信、服务、进取的价值观，坚持以客户为中心、客户至上的服务理念，以“关注企业需求，实现企业价值”为导向，努力为企业提供全面优质的互联网应用服务。服务包括空间域名、虚拟主机、企业邮箱、网站建设、网站优化、网络营销解决方案和咨询服务，以帮助企业客户应用互联网。
1. 病号是谁（WHO）？
拿出控制台诊断仪器，输入 top 命令一探究竟。我勒个去，不看不知道一看吓一跳，PID 为 1878 的病号，CPU 占用居然 200% 多。
问题算是定位到了，但是 PID 为 1878 的病号到底是谁，难道真是昨天上线的看门狗 ？
虽然大刘久经职场，但是排查生产问题时，内心还是比较忐忑，毕竟这是生产环境。
说时迟那时快，只见大刘一个命令输入：
ps -ef | grep 1878
定睛一看，原来是放屁瞅别人，短信服务自己在作祟，和看门狗没关系，大刘心里一下子平缓了不少。
锅找到了主儿，其实这个时候大刘完全可以把这个问题甩给短信开发团队，但是大刘最喜欢做的不是甩锅，而是打破砂锅刨到底。
2. 病号哪里出了问题（WHERE）？
为什么 1878 号病人占用 CPU 会这么高呢？
只见黑乎乎的控制台诊断仪器上，大刘熟练的输入：
jstack -l 1878 >> 1878号病历.log
这样便得到一份 1878 号病人的病历详情单，一会儿用得上。
到底 1878 号病人的哪个部位出了问题呢？
话没说完，只见大刘又在控制台诊断仪器上，输入一个：
top -Hp 1878
白板黑字，把 1878 号病人的器官信息全部列了出来。
看到结果，甚是一惊，PID 代号为 8721 的器官占用 CPU 100% 多。
疑惑油然而生，这个 PID 代号 为 8721 的器官是啥，是头、是眼睛、还是胳膊腿呢？这些器官展示的 PID 列都是昵称，都这么善于伪装，如何揭露它的真面目呢？
还好大刘有高招，借助照妖镜算法，熟练的输入：
printf "%x\n" 8721
果真使得代号为 8721 的器官，现了真身，真实身份居然是 2211 的呼吸道，怪不得病号一直气喘吁吁，上气不接下气。
到这一步还无法对症下药啊，还需要进一步确诊 2211 的呼吸道到底出了什么幺蛾子，导致 1878 号病人一直气喘吁吁，上气不接下气？
只见黑乎乎的控制台诊断仪器上，大刘再次飞一般的在输入：
grep 2211 -A20 1878号病历.log
诊断结果随之显示在诊断仪器上。
曾经背了很多锅的大刘，看到诊断结果心里乐了一下，一眼就看出是高并发情况下用了 HashMap 的问题（请大家们自行寻找谷歌、百度，就不在此深入展开啦），终于拨开云雾见青天。
3. 如何对症下药（ HOW ）？
在大刘行云流水没有一丝一毫的拖泥带水般的神操作下，1878 号病人的诊断也就结束了，这个锅就彻底被打破了。
术业有专攻，大刘就可以郑重的告诉短信开发同事具体原因了，捉得病根，开发同事也就可以对症下药啦。
大刘这套行走江湖的诊断问题方式你 get 到了没？大刘自己简单概括为 2W1H 三板斧：病号是谁、病号哪里出了问题、对症下药。
1、病号是谁？（WHO）
2、病号哪里出了问题？（WHERE）
第一步：采用 jstack -l PID >> PID.log 获取病号的各器官信息的病历单；
第二步：采用 top -Hp PID 拿到占用 CPU 最高的器官昵称 PID ;
第三步：采用 printf "%x\n" PID 根据器官昵称 PID 的拿到器官真实身份 TID ;
第四步：采用 grep TID -A20 pid.log 根据 TID 去病历单中匹配，确定是哪出了问题。
3、捉得病根、便可拿出医药箱，对症下药啦。（HOW）
作为程序猿，工作中难免会遇到不少类似这样的问题。面对问题，你如果像无头苍蝇一样乱撞，撞得头破血流依然不知道缘由，在背锅即将成为现实时，那就不妨试试2W1H 三板斧的诊断方式，说不定会帮你快速定位、解决线上问题，毕竟快速的解决生产问题会把损失降到最低。
“架构出错时如何进行查询”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站，小编将为大家输出更多高质量的实用文章！
分享文章：架构出错时如何进行查询
转载源于：
http://cdkjz.cn/article/ihshpp.html
