Linux

Linux下高cpu解决方案(转载)

昨天搞定了一个十万火急的issue,客户抱怨产品升级后系统会变慢和CPU使用率相当高,客户脾气很大,声称不尽快解决这个问题就退货,弄得我们 R&D压力很大,解决这个issue的任务分给了我,客户是南非的一个公司,由于时差问题,我只好在家远程解决问题,晚上8点半用 gotomeeting远程到客户电脑查看我们的系统,折腾了四个多小时,终于在凌晨时reproduce了这个high CPU,赶紧抓Log,用wireshark抓包,用gcore,gstack,strace和top保存了系统的相关输出。在第2天分析了这些文件后, 找到了产品的bug,代码的作者分配了10K的缓冲区,并想当然认为10K足以够用,当然99%的情况下是够用的,但是在这1%的情况下出现了问题,缓冲 区不幸被写满了,然后程序进入了死循环,导致high CPU。找到了问题了,fix就很容易了,客户的脾气也缓和了,fix很快就可以deliver给客户。反思解决问题的过程,觉得这个分析过程具有可复用 性,值得总结一下。…

用 netstat 命令,分析网络连接情况

  1. // 用jps命令,显示所有JAVA进程。
  2. # jps
  3. 18374 DesktopServerLauncher
  4. 14690 Bootstrap
  5. 23211 Jps
  6. //除了jps那行,其余全是JAVA进程。
  7. // 用netstat命令,显示进程ID和程序名(p);然后用grep命令找出进程18374;然后用head命令显示前3行。
  8. # netstat -antp | grep 18374 | head –3
  9. tcp        0      0 :::54104                    :::*                        LISTEN      18374/java
  10. tcp        0      0 ::ffff:

Linux环境下的性能分析 之 IO篇

这周继续上上周的话题,关于linux下的一些性能分析。之前我们聊了CPU、内存的性能分析方法,这周我们聊聊关于磁盘IO的性能分析。

之前之所以去百度学道,就是因为老王在自己在学校瞎折腾的时候,发现自己的服务器如果压力稍微大一些,就扛不住,而且能很明显的听到磁盘哐哧哐哧飞速旋转的声音。所以,决心去bd看看,大公司是怎么样解决磁盘性能问题的。后来去贴吧学艺,正好接手了贴子存储系统的重构工作,后来和另外一个同事合作,完成了贴吧百亿贴子存储系统的研发,也算完成了当年的夙愿。当时做这个系统开发的时候,对于存储系统的研究还是比较多,今天就抽一些关于性能分析的方法给大家聊聊。…

Linux环境下的性能分析 之 内存篇

最近雾霾很严重,即使周末想必大家也很难得出门。与其在外面吸霾,不如在家看老王扯扯技术的淡。好了,言归正传,今天延续上周的话题,我们聊聊在linux下如何分析内存的性能。

 

上周有朋友给老王建议,说能不能用例子的方式来讲这一部分的内容?老王觉得是一个很好的建议。所以,老王就准备讲一个前一段时间发生的例子。也不知道效果好不好,姑且一试,讲的不好不要打我哈(即使要打也请不要打脸,不然周一没法上班~)…

Linux服务器的那些性能参数指标

一个基于Linux操作系统的服务器运行的同时,也会表征出各种各样参数信息。通常来说运维人员、系统管理员会对这些数据会极为敏感,但是这些参数对于开发者来说也十分重要,尤其当你的程序非正常工作的时候,这些蛛丝马迹往往会帮助快速定位跟踪问题。
这里只是一些简单的工具查看系统的相关参数,当然很多工具也是通过分析加工/proc、/sys下的数据来工作的,而那些更加细致、专业的性能监测和调优,可能还需要更加专业的工具(perf、systemtap等)和技术才能完成哦。毕竟来说,系统性能监控本身就是个大学问。
linux-performance

一、CPU和内存类

1.1 top

➜ ~ top
linux-top
第一行后面的三个值是系统在之前1、5、15的平均负载,也可以看出系统负载是上升、平稳、下降的趋势,当这个值超过CPU可执行单元的数目,则表示CPU的性能已经饱和成为瓶颈了。

第二行统计了系统的任务状态信息。running很自然不必多说,包括正在CPU上运行的和将要被调度运行的;sleeping通常是等待事件(比如IO操作)完成的任务,细分可以包括interruptible和uninterruptible的类型;stopped是一些被暂停的任务,通常发送SIGSTOP或者对一个前台任务操作Ctrl-Z可以将其暂停;zombie僵尸任务,虽然进程终止资源会被自动回收,但是含有退出任务的task descriptor需要父进程访问后才能释放,这种进程显示为defunct状态,无论是因为父进程提前退出还是未wait调用,出现这种进程都应该格外注意程序是否设计有误。

第三行CPU占用率根据类型有以下几种情况:
(us) user: CPU在低nice值(高优先级)用户态所占用的时间(nice<=0)。正常情况下只要服务器不是很闲,那么大部分的CPU时间应该都在此执行这类程序
(sy) system: CPU处于内核态所占用的时间,操作系统通过系统调用(system call)从用户态陷入内核态,以执行特定的服务;通常情况下该值会比较小,但是当服务器执行的IO比较密集的时候,该值会比较大
(ni) nice: CPU在高nice值(低优先级)用户态以低优先级运行占用的时间(nice>0)。默认新启动的进程nice=0,是不会计入这里的,除非手动通过renice或者setpriority()的方式修改程序的nice值
(id) idle: CPU在空闲状态(执行kernel idle handler)所占用的时间
(wa) iowait: 等待IO完成做占用的时间
(hi) irq: 系统处理硬件中断所消耗的时间
(si) softirq: 系统处理软中断所消耗的时间,记住软中断分为softirqs、tasklets(其实是前者的特例)、work queues,不知道这里是统计的是哪些的时间,毕竟work queues的执行已经不是中断上下文了
(st) steal:

Page 1 of 612345...Last »