1.操作系统状态监控
每天登陆系统查看系统运行的负荷如何，有无报错日志或报警日志。 2.操作系统故障排除
依据操作系统故障日志分析出现该报警或报错的原因，从而解决问题，保证操作系统的高可用性。 3.服务器状态确认
服务器上除了跑着操作系统，必然会安装一些应用程序或数据库，运维工程师每天需要查看linux系统上运行着的应用程序或数据库状态是否正常。 4.备份
运维工程师的看家本事，数据库备份和恢复，一般来说只要给数据库制定了备份策略它会自己备份，你只需要监控备份任务是否执行了就可以。 5.服务器调优
这个要求就比较高了，linux随着使用时间的增长，状态会有所下降，运维工程师有能力的可以对操作系统及数据库进行性能调优，保证系统处于一个最佳状态。
性能测试监控——CPU
为了全面详细的分析系统运行状态，发现隐藏的性能瓶颈。性能测试期间，全面监视CPU运行状态是很有必要的。
本文侧重分析性能测试期间需要监控的CPU运行状态指标，对比相关查询命令的优劣，并给出最终的shell脚本。 关于各指标的详细含义，见附件。
一、 监控指标项及其理想值
1、load average，平均每个逻辑内核不能高于0.7。
load average大于1，表示系统中存在处于等待状态的任务，任务竞争CPU容易导致
性能降低，时延增大，甚至进入恶性循环。在一个合理的load average下加压，监测CPU使用率的变化情况，可以帮助发现I/O、内存、网络中的性能瓶颈。
2、CPU总占有率。总占有率小于70%，其中以%usr为主，%sys和%iowait不能太高。
3、各逻辑内核CPU占有率持平。 4、执行相同任务的进程CPU占有率持平。 5、进程状态合理，僵死进程不能太多。
二、 数据收集
数据收集的重点与核心在于：
详实而又不冗余，不关注无关指标，以最少的数字反应关注的指标。
有的指标项，比如各逻辑内核的CPU占有率持平，关注的是一组数据的分布特点，而不关心数据的具体值。同时，当前系统性能的瓶颈主要在I/O。数据收集期间记录全部数据的具体数值，即降低影响系统性能，又加大了后期数据处理的工作量。
故，数据收集之前，对我们所需要的数据的统计特征进行分析。
1. load average
每隔1min，5min或15min取该段时间内的load average即可。一次取1个数据。 shell命令：uptime | awk -F: '{print $NF}'|awk -F, '{print $1}' 命令解释：
uptime获取load average。
awk -F: '{print $NF}'提取1min，5min或15min 内load average的具体数值。 awk -F, '{print $1}'提取其中1个字段。
2. CPU总占有率
每隔一段时间，取当前的%usr,%sys,%iowait,%idle取值。
shell命令：mpstat|grep all
解释：mpstat的输出参数，无法自定义字段。其中部分字段是我们暂时不关注，但后续会关注。另外，剔除这些字段涉及较多的管道和文本分析，较为复杂。同时，降低了脚本的可移植性。
3. 各逻辑内核CPU占有率持平
根据各逻辑内核的CPU占有率计算：跨度（（max-min）/average），mdev（sqrt（平方和的平均值-平均值的平方）） 命令：
mpstat -P ALL|grep -v -i ALL|grep -o -e '[0-9][0-9]*\\..*\\.[0-9]*[0-9]$'|awk -v col=9 -f cal.awk
其中用到了脚本 cal.awk 解释：
mpstat -P ALL|grep -v -i ALL|grep -o -e '[0-9][0-9]*\\..*\\.[0-9]*[0-9]$' 提取各CPU的指
标的数据。
col=9，列数。
cal.awk脚本计算数据值的跨度和mdev BEGIN {
for(i=1;i<=col;i++){ sum[i] = 0; squsum[i] = 0; max[i] = 0;
min[i] = 1000000; } } {
for(j=1;j<=col;j++) { tmp = $j sum[j] += tmp
squsum[j] += tmp*tmp if(max[j] for(k=1;k<=col;k++) { ave = sum[k]/NR mdev = sqrt(squsum[k]/NR-ave*ave) printf(\"%.2f/%.2f/%.2f/%.2f \"), ave,max[k],min[k],mdev } } 4. 执行相同任务的进程CPU占有率持平 算法同上。 命令： # ps aux |grep nginx|grep -v grep|awk '{print $3}'|awk -v col=1 -f cal.awk ave/max/min/mdev = 2.59/3.00/0.00/0.92 三、 脚本化 定时（每分钟）输出cpu运行状态信息到指定文件（cpu_yjk.log）。 为了方便后续用python进行数据分析，输出格式统一如下： 1、每次输出独占且只占用一行。 2、数据项之间以“，”分隔。 3、涉及统计数字的数据项，以ave/max/min/mdev格式输出计算结果 #!/bin/bash sleepTime=60 logfile=cpu_yjk.log if [ -f \"$logfile\" ]; then rm cpu_yjk.log fi exec 1>$logfile processName=\"watchCpu.sh\" title=\"load\" coretitle=`mpstat | grep -o -e '%.*'` #print title printf \"%s,\" `date +%Y-%m-%d_%H:%M:%S` printf \"%6s,\" $title printf \"%12s(ave/max/min/mdev),\" $coretitle printf \"%12s(ave/max/min/mdev),\" $processName printf \"\\n\" while true do load=`uptime | awk -F: '{print $NF}'|awk -F, '{print $1}'` corevalue=`mpstat -P ALL|grep -v -i ALL|grep -o -e '[0-9][0-9]*\\..*\\.[0-9]*[0-9]$'|awk -v col=9 -f cal.awk` processValue=`ps aux |grep $processName|grep -v grep|awk '{print $3}'|awk -v col=1 -f cal.awk` #print value printf \"%s,\" `date +%Y-%m-%d_%H:%M:%S` printf \"%6.2f,\" $load printf \"%30s,\" $corevalue printf \"%30s,\" $processValue printf \"\\n\" sleep $sleepTime done 附录——指标项详细分析 一、 load average 1. 指标项含义： Load：简单的说是进程队列的长度(WikiPedia：the system Load is a measure of the amount of work that a compute system is doing）。 Load Average:一段时间（1分钟、5分钟、15分钟）内平均Load。 即一段时间内正在使用和等待使用CPU的统计信息（平均任务数）。 Unix系统，队列长度主要看：正在执行的进程数、等待的进程数。 Linux系统，在Unix之上增加不可中断的进程数。 2. 察看命令： uptime： load average后的三个数字依此是过去1min，5min，15min的平均负载。 w：同时显示已登录的用户。打开2个shell标签页，显示两个shell端。 cat /proc/loadavg top：占用资源较多，不适合写入脚本。 tload 画图形 procinfo： ubuntu 12.04 需要单独安装。Suse系统默认没有安装。 3. 指标项取值： 单个CPU核心上的负载为1，表示表示系统没有剩余资源，同时恰好没有等待资源。 但是，任何的异常都会导致出现排队等待序列，进入恶性循环。 一般认为，单核的理想附负载值为0.7，也有0.5-0.6一说。 若多个CPU，则计算每个CPU逻辑核心的平均值。 多核处理器的理想负载值：0.7*逻辑CPU个数。 逻辑CPU个数查看命令：grep 'model name' /proc/cpuinfo | wc -l 二、 CPU占有率 1. 指标细分 CPU使用率从以下3个方面监控： 1、具体进程的CPU占有率及其随时间的变化规律（纵向对比）。 不能超过特定数值或百分比。 2、各CPU独立内核CPU占有率分配情况（横向对比）。 横向分配均匀。 2. 查看CPU核心的运行情况 主要有sar，mpstat，vmstat，top。 其中，top消耗资源较多，不适合在性能期间持续运行。 mpstat可以查看各个CPU核心的负载情况，可以设定刷新时间和次数。比较适合。 sar linux198:~ # sar 1 3 Linux 2.6.16.46-0.12-smp (linux198) 07/26/12 18:03:41 CPU %user %nice %system %iowait %idle 18:03:42 all 14.76 0.00 4.09 0.00 81.14 18:03:43 all 13.95 0.00 1.99 0.25 83.81 18:03:44 all 9.31 0.00 5.58 1.36 83.75 Average: all 12.67 0.00 3.89 0.54 82.90 mpstat linux39:~ # mpstat -P ALL 3 4 Linux 2.6.16.46-0.12-smp (linux39) 07/26/12 15:35:37 CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s 15:35:40 all 2.24 0.00 1.29 0.04 0.04 1.41 0.00 94.97 7645.70 15:35:40 0 0.33 0.00 0.33 0.00 0.00 0.00 0.00 99.34 0.00 15:35:40 1 1.66 0.00 1.32 0.00 0.00 0.99 0.00 96.36 1527.81 15:35:40 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 99.34 5.96 15:35:40 3 6.62 0.00 2.32 0.00 0.00 4.30 0.00 86.75 2905.63 15:35:40 4 0.33 0.00 0.66 0.00 0.00 0.00 0.00 98.68 0.00 15:35:40 5 0.66 0.00 0.33 0.66 0.00 0.33 0.00 97.68 109.27 15:35:40 6 8.28 0.00 5.63 0.00 0.00 5.96 0.00 80.46 2807.95 15:35:40 7 0.33 0.00 0.33 0.00 0.00 0.00 0.00 98.68 289.40 vmstat linux198:~ # vmstat 1 3 procs -----------memory---------- - --swap-- -----io---- -system- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 4499660 10534364 29408 1725604 0 1 12 14 1 3 23 5 72 0 3 0 4499660 10549164 29408 1715324 0 0 0 48 2847 12769 29 12 59 0 0 1 0 4499660 10549500 29408 1715324 0 0 0 0 2157 12800 16 3 81 0 0 Procs 0 r: The number of processes waiting for run time.即load average CPU These are percentages of total CPU time. us: Time spent running non-kernel code. (user time, including nice time) sy: Time spent running kernel code. (system time) id: Time spent idle. Prior to Linux 2.5.41, this includes IO-wait time. wa: Time spent waiting for IO. Prior to Linux 2.5.41, shown as zero. st: Time spent in involuntary wait. Prior to Linux 2.6.11, shown as zero. top 分析%usr ：%sys ：%wio的情况， %usr是指CPU用于执行应用程序百分比， %sys是指CPU应用执行系统程序（通常是操作系统的系统调用）的百分比， %wio是指CPU在等待IO的百分比。 通常情况下，%sys和%wio都不应该太高，否则就说明应用程序设计不合理，需要分析原因。 完成同样功能的应用程序，其CPU占用率应该大致相等，否则说明系统负荷分配不均匀。 对于多CPU的系统，各CPU的占用率也应该大致相等，否则说明系统对CPU资源的使用不均衡，需要优化配置。 总的CPU平均占用率不应该太高，如超过90％，否则说明可能系统性能已经受限于CPU资源。 3. 查看进程的CPU运行情况 ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 780 76 ? S Jul13 0:09 init [3] root 2 0.0 0.0 0 0 ? S Jul13 0:00 [migration/0] root 3 0.0 0.0 0 0 ? SN Jul13 0:00 [ksoftirqd/0] root 4 0.0 0.0 0 0 ? S Jul13 0:00 [migration/1] root 5 0.0 0.0 0 0 ? SN Jul13 0:00 [ksoftirqd/1] root 6 0.0 0.0 0 0 ? S Jul13 0:00 [migration/2] root 7 0.0 0.0 0 0 ? SN Jul13 0:00 [ksoftirqd/2] linux上进程有5种状态: 1. 运行(正在运行或在运行队列中等待) 2. 中断(休眠中, 受阻, 在等待某个条件的形成或接受到信号) 3. 不可中断(收到信号不唤醒和不可运行, 进程必须等待直到有中断发生) 4. 僵死(进程已终止, 但进程描述符存在, 直到父进程调用wait4()系统调用后释放) 5. 停止(进程收到SIGSTOP, SIGSTP, SIGTIN, SIGTOU信号后停止运行运行) ps工具标识进程的5种状态码: D 不可中断 uninterruptible sleep (usually IO) R 运行 runnable (on run queue) S 中断 sleeping T 停止 traced or stopped Z 僵死 a defunct (\"zombie\") process 注: 其它状态还包括W(无驻留页), <(高优先级进程), N(低优先级进程), L(内存锁页). 4. 性能测试关注指标及查看命令 性能测试期间，不能有大量僵死进程。 完成同样功能的进程，CPU占有率相近。 关键进程运行状态正常，CPU占有率正常。是否需要特定进程的实时CPU占有率？个人认为不需要，因为，端到端场景中，往往需要多个进程之间协作，关心特定进程的占有率意义不大，关心全部进程占有率工作量太大且无明显意义。只要保证进程状态正常，CPU整体占有率合适且各内核占有率均衡即可。 所以，命令上选择：mpstat和ps aux 三、 CPU信息查看 /proc/cpuinfo查看cpu的参数信息，性能测试时主要关心逻辑内核总数。 processor 条目包括这一逻辑处理器的唯一标识符 physical id相同的是同一个物理CPU。 core id相同的是同一个核的超线程。 siblings 条目列出了位于相同物理封装中的逻辑处理器的数量。 1. 逻辑CPU总个数： # cat /proc/cpuinfo | grep “processor” | wc -l 2. 物理CPU个数： # cat /proc/cpuinfo | grep “physical id” | sort | uniq | wc -l 3. 每个物理CPU中Core的个数： # cat /proc/cpuinfo | grep “cpu cores” | wc -l 4. 是否为超线程 如果有两个逻辑CPU具有相同的”core id”，那么超线程是打开的。 5. 每个物理CPU中逻辑CPU个数： # cat /proc/cpuinfo | grep “siblings” 逻辑CPU个数：cat /proc/cpuinfo | grep \"processor\" | wc -l 物理CPU个数：cat /proc/cpuinfo | grep \"physical id\" | sort | uniq | wc -l “siblings”指的是一个物理CPU有几个逻辑CPU ”cpu cores“指的是一个物理CPU有几个核 不应该按照flags里是否有 ht 标志来判断系统是否有超线程能力，而应该： 如果“siblings”和“cpu cores”一致，则说明不支持超线程，或者超线程未打开。 如果“siblings”是“cpu cores”的两倍，则说明支持超线程，并且超线程已打开。 6. 查看cpu型号 # cat /proc/cpuinfo | grep name | cut -f2 -d: | uniq -c 2 Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz (看到有2个逻辑CPU, 也知道了CPU型号) 7. 查看cpu运行模式 # getconf LONG_BIT 32 (说明当前CPU运行在32bit模式下, 但不代表CPU不支持64bit) 8. 查看cpu是否支持64bit # cat /proc/cpuinfo | grep flags | grep ' lm ' | wc -l 2 (结果大于0, 说明支持64bit计算. lm指long mode, 支持lm则是64bit) 9. 查看cpu信息概要 #lscpu Architecture: i686 #架构686 CPU(s): 2 #逻辑cpu颗数是2 Thread(s) per core: 1 #每个核心线程数是1 Core(s) per socket: 2 #每个cpu插槽核数/每颗物理cpu核数是2 CPU socket(s): 1 #cpu插槽数是1 Vendor ID: GenuineIntel #cpu厂商ID是GenuineIntel CPU family: 6 #cpu系列是6 Model: 23 #型号23 Stepping: 10 #步进是10 CPU MHz: 800.000 #cpu主频是800MHz Virtualization: VT-x #cpu支持的虚拟化技术VT-x L1d cache: 32K #一级缓存，具体为L1数据缓存为32k L1i cache: 32K # 一级缓存，具体为L1指令缓存为32K L2 cache: 3072K #二级缓存3072K CPU使用率可分为一下几个部分 User Time—执行用户进程的时间百分比； System Time—执行内核进程和中断的时间百分比； Wait IO—因为IO等待而使CPU处于idle状态的时间百分比； Idle—CPU处于Idle状态的时间百分比。 1. Linux系统出现了性能问题，一般我们可以通过top.iostat,vmstat等命令来查看初步定 位问题。其中iostat可以给我们提供丰富的IO状态数据。 2. iostat结果分析 3. [kefu@SZ-8 tengkefeng]$ iostat -x -k 4. Linux 2.6.18-128.el5_cyou_1.0 (SZ-8.30) 09/08/2011 5. 6. avg-cpu: %user %nice %system %iowait %steal %idle 7. 16.58 0.00 2.79 0.46 0.00 80.16 8. 9. Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq -sz avgqu-sz await svctm %util 10. sda 0.06 29.28 0.22 37.14 10.21 265.68 14 .77 0.02 0.51 0.15 0.55 11. sda1 0.00 0.00 0.00 0.00 0.00 0.00 10 .79 0.00 2.66 2.43 0.00 12. sda2 0.01 0.78 0.10 0.36 0.81 4.58 23 .51 0.00 1.21 0.84 0.04 13. sda3 0.03 15.17 0.09 35.39 8.98 202.24 11 .91 0.01 0.26 0.12 0.44 14. sda4 0.00 0.00 0.00 0.00 0.00 0.00 2 .00 0.00 33.33 33.33 0.00 15. sda5 0.01 1.59 0.03 0.51 0.34 8.40 32 .20 0.00 1.19 0.58 0.03 16. sda6 0.00 0.00 0.00 0.12 0.00 0.48 8 .18 0.00 5.02 4.53 0.05 17. sda7 0.00 0.00 0.00 0.00 0.00 0.00 45 .00 0.00 5.52 3.04 0.00 18. sda8 0.00 0.00 0.00 0.00 0.00 0.00 40 .88 0.00 7.62 6.03 0.00 19. sda9 0.00 0.00 0.00 0.00 0.00 0.00 39 .71 0.00 7.37 5.83 0.00 20. sda10 0.00 0.00 0.00 0.00 0.00 0.00 37 .57 0.00 5.70 3.54 0.00 21. sda11 0.00 11.74 0.01 0.76 0.08 49.97 131 .48 0.01 10.74 0.57 0.04 22. sdb 0.01 3.91 20.24 20.21 1262.95 1853.94 154 .09 0.52 12.84 1.97 7.95 23. 24. rrqm/s:每秒进行merge的读操作数目。即delta(rmerge)/s 25. wrqm/s:每秒进行merge的写操作数目。即delta(wmerge)/s 26. r/s:每秒完成的读I/O设备次数。即delta(rio)/s 27. w/s:每秒完成的写I/0设备次数。即delta(wio)/s 28. rsec/s:每秒读扇区数。即delta(rsect)/s 29. wsec/s:每秒写扇区数。即delta(wsect)/s 30. rKB/s:每秒读K字节数。是rsec/s的一半，因为每扇区大小为512字节 31. wKB/s:每秒写K字节数。是wsec/s的一半 32. avgrq-sz:平均每次设备I/O操作的数据大小(扇区)。即 delta(rsect+wsect)/delta(rio+wio) 33. avgqu-sz:平均I/O队列长度。即delta(aveq)/s/1000(因为aveq的单位为毫秒) 34. await:平均每次设备I/O操作的等待时间(毫秒)。即 delta(ruse+wuse)/delta(rio+wio) 35. svctm:平均每次设备I/O操作的服务时间(毫秒)。即delta(use)/delta(rio+wio) 36. %util:一秒中有百分之多少的时间用于I/O操作,或者说一秒中有多少时间I/O队列是非空 的。即delta(usr)/s/1000(因为use的单位为毫秒) 37. 38. 如果%util接近100%,说明产生的I/O请求太多,I/O系统已经满负载,该磁盘可能存在瓶 颈。 39. 40. 比较重要的参数 41. %util:一秒中有百分之多少的时间用于I/O操作，或者说一秒中有多少时间I/O队列是非空的 42. svctm:平均每次设备I/O操作的服务时间 43. await:平均每次设备I/O操作的等待时间 44. avgqu-sz:平均I/O队列长度 45. 46. 如果%util接近100%,表明I/O请求太多,I/O系统已经满负荷，磁盘可能存在瓶颈,一般%util大于70%,I/O压力就比较大，读取速度有较多的wait。 47. 同时可以结合vmstat查看查看b参数(等待资源的进程数)和wa参数(I/O等待所占用的CPU时间的百分比,高过30%时I/O压力高) 48. await的大小一般取决于服务时间(svctm)以及I/O队列的长度和I/O请求的发出模式。如果svctm比较接近await,说明I/O几乎没有等待时间;如果 49. await远大于svctm,说明I/O队列太长，应用得到的响应时间变慢。 50. 51. 形象的比喻 52. r/s+w/s类似于交款人的总数 53. 平均队列长度(avgqu-sz)类似于单位时间里平均排队的人数 54. 平均服务时间(avctm)类似于收银员的收款速度 55. 平均等待时间(await)类似于平均每人的等待时间 56. 平均I/O数据(avgrq-sz)类似于平均每人所买的东西 57. I/O操作率(%util)类似于收款台前有人排队的时间比例 58. 59. svctm一般要小于await(因为同时等待的请求的等待时间被重复计算了),svctm的大小一般和磁盘性能有关,CPU/内存的负荷也会对其有影响，请求过多也会 60. 间接导致svctm的增加。await的大小一般取决于服务时间(svctm)以及I/O队列的长度和I/O请求的发出模式。如果svctm比较接近await,说明I/O几乎没有 61. 等待时间;如果await远大于svctm,说明I/O队列太长，应用得到的响应时间变慢,如果响应时间超过了用户可以容许的范围,这时可以考虑更换更快的磁盘,调 62. 整内核elevator算法,优化应用,或者升级CPU 63. 64. 队列长度(avcqu-sz)也可作为衡量系统I/O负荷的指标,但由于avcqu-sz是按照单位时间的平均值,所以不能反映瞬间的I/O洪水。 因篇幅问题不能全部显示，请点此查看更多更全内容