这部技术葵花宝典真的很硬核

你有没有经历过：一大早就被疯狂的报警炸醒，由于线上应用 CPU 占用率过高 ......

你有没有经历过：刚到公司，板凳还没有捂热，收件箱里却一堆的客服投诉邮件，需要你排查日志定位问题 ...... 

你有没有经历过：下班的钟声即将敲响，但是你还要加班，进行统计应用每秒、每分钟的峰值等各个指标 ，由于 BOSS 要拿这些指标，在明天的技术大会上对外吹牛 ......

你有没有经历过：深夜正在酣眠，值班的运维疯狂给你打 CALL，由于线上应用内存出现了问题 ......

我敢保证上面的场景，大概率你都经历过。讲真，其实无论你是否经历过，今天你都算来着啦。因为我将要结合以往的经历总结，在猿门开坛设法，掏出葵花宝典施展一二。

水滴石穿非一日之功，冰冻三尺非一日之寒，罗马并非一日建成的，经验也并非一坑而促成的，防狼有术，我们先从全局，看一看这部技术宝典（看不清没关系，感觉到很牛掰就行）。

这部技术宝典真的很硬核，主要分四大招，见招拆招，让我们一一进行拆解。

第 1 招：线上应用占用 CPU 过高。

拆～招：

采用 top 命令，找出 CPU 占用最高的进程 PID；	
通过 ps -ef | grep PID 查看对应的应用，看看是谁在作祟；	
采用 jstack -l  PID >> PID.log 获取进程的堆栈信息；	
采用 ps -mp PID -o THREAD,tid,time 拿到占用 CPU 最高的线程 tid；	
采用 printf "%x\n" tid 获取 16 进制的线程 TID；	
采用 grep TID -A20 PID.log 确定是线程哪儿出了问题。

最～后：腿疼医腿，辨症施治，对症下药。找准代码位置，进行调整代码。

第 2 招：线上应用内存溢出。

拆～招：

采用 top 命令，找出应用对应的 PID；	
采用 jmap -heap PID 确认一下分配的内存少不少；	
采用 jmap -histo:live PID | more 找出分析最耗内存的对象【留意占用多少G的对象】；	
采用 ps -efL | grep PID | wc -l 查看进程创建的线程数；	
采用 ll /proc/PID/task | wc -l 也可以查看进程创建的线程数；	
采用 netstat -apn | grep PID | wc -l 查看进程网络连接数。

最～后：腿疼医腿，辨症施治，对症下药。

a. 如果内存分配确实小，适当调整内存；	
b. 对象被频繁创建，且不释放，优化代码；	
c. 不断创建线程或者不断进行网络连接，优化代码。

第 3 招：排查业务问题。

拆～招：

采用 tail -fn 200 log_file 实时查询线上日志；	
找准日志搜所关键字keyWord，例如 orderId、mobileId、reqId 等；	
采用 grep keyWord log_file 查询关键字所在的行的日志；	
采用 grep -C n keyWord log_file 匹配关键字所在行的上下 n 行；	
采用 grep keyWord log_file | wc -l 匹配关键字的的行数有多少。

最～后：根据实际排查日志场景进行日志搜索 tail 、grep 用的最多。

第 4 招：BOSS 的统计问题。

拆～招：

采用 cat log_file 读取日志文件；	
采用 cut 命令截取出日志的时间戳；	
若按照秒统计截取到秒；若按照分钟统计截取到分钟；	
采用 uniq -c 进行去重统计；	
采用 sort -nr 按照第一列的数值大小进行倒序；	
采用 head -1 只显示第一行内容。

最～后：统计问题迎刃而解，那么统计每秒峰值的命令该如何写呢？

例如日志: 

1118 115856 066 - REQID0000000000188 ... ...

命令组合：

SecondPeak=`cat log_file|cut -d, -f1| cut -c 1-11|sort|uniq -c |sort -nr|head -1`

好了，今天的分享接近尾声，不知道你 get 到多少，懂与不懂，都建议你收藏，以备不时之需。