0 硬件性能对业务的意义
在硬件层面，主要有cpu、内存、磁盘、网络这几方面。每个方面都可能成为性能瓶颈，从而影响业务的正常运行。
1 cpu
1.1 load average
系统平均负载，在特定时间间隔内运行队列中的平均进程数量。在以下爆表案例中，平均15m有33个进程在队列中，5m有31个，1m有32个，属于持续化的爆表。
这是一台4core的机器，所以分担到每个core上，有8个进程在运行或排队。这种情况下，大量进程无法获取cpu资源，导致无法获得运行结果。
业务基本瘫痪。
一般来说，load average 会在5以下。
1.2 cpu util（利用率）
top命令下按‘1’，就会显示每个core的使用情况。需要关注的是us(user time)，sy(system time)，id(idel time)。
以下是一台业务健康服务器的cpu利用率状态。
在1.1的爆表案例中，id为0，在zabbix的cpu util图中会这样，红色是sy，蓝色是us，绿色是id。没有绿色，cpu已爆。
%cpu一栏表示一个进程占用的cpu百分比，100%表示跑满一个core。就是说4core的机器，理论上最高可达400%。但一般来说，跑到100%已经是问题户了。有两种情况，要么业务真的负载太大，需要架构调整，要么进程出现内部错误，需要重启进程或者调整程序内部错误。
按P可以按cpu降序排列。
1.3 进程状态
在1.1的图中，Tasks一栏显示，一共有201个进程，17个在运行，184个在休眠。
在以下图中，S一栏表示进程状态，R是running，S是sleeping，一般来说，大部分时间S，小部分时间切换到R。在1.1案例中，R状态是持续性的。下判断，进程内部错误，出现死循环，持续占用cpu不释放，让队列深度飙高。杀进程-->优化程序内部逻辑。
2 memery
2.1 系统级内存状态
服务器上的内存主要服务于两个方面：支持业务进程的运行，支持系统层面的操作（比如查日志、解包等）。在内存的使用上，如果剩余内存过少，这时有一个比较大的系统操作，或者业务进程并发增多，系统可能会杀进程，所以要预留一部分内存。我定的预留量是800M。
[root@VM ~]# free -m
total used free shared buffers cached
Mem: 7870 7474 395 0 25 2944
-/+ buffers/cache: 4505 3365
Swap: 0 0 0
#total7870M内存，free395M。这是在OS层面的。有（25+2944）M被缓存起来用于了，对程序来说，实际可用的是3365M，这个数是我们需要关注的。
2.2 进程级内存状态
top下按M，进程按RES(内存)排序
2.3 内存不足系统杀进程
[root@VM_3_2_centos]# dmesg | tail [437421.447859] [25087] 0 25087 141212 25226 0 0 0 xxx [437421.447861] [25321] 0 25321 25491 150 0 0 0 YDLive [437421.447863] [25343] 0 25343 1016 43 1 0 0 mingetty [437421.447865] [25344] 0 25344 1016 44 0 0 0 mingetty [437421.447867] [25345] 0 25345 1016 43 0 0 0 mingetty [437421.447868] [25346] 0 25346 1016 43 0 0 0 mingetty [437421.447870] [25347] 0 25347 1016 44 0 0 0 mingetty [437421.447873] [25348] 0 25348 1016 42 0 0 0 mingetty [437421.447874] Out of memory: Kill process 4830 (xxx) score 1 or sacrifice child [437421.447878] Killed process 4830, UID 0, (xxx) total-vm:952616kB, anon-rss:21920kB, file-rss:1400kB #当系统内存不足，会随机杀进程，以保证系统正常运行。 #在系统信息里可以看到相关杀进程信息。
3 disk
这里我们关注3个指标，iops，就是每秒的磁盘io次数。读写速度，就是每秒io的量。等待和磁盘利用率，说明磁盘负载情况。
3.1 iops
iops -x 60 5（显示详细信息，采样周期60s，次数5）
下图，就是由于定时任务大量压缩日志而导致读io频率特别高的一个场景。db和log服务器这种依赖磁盘的服务，一般在iops上都会容易出现瓶颈。
可以用iostat命令来查iops。下图就是采样周期为60s的数据采集，第二块磁盘的读iops为36，写io为24。
3.2 await和%util
await表示io的等待时间。单位是ms。一般来说，连续30s的显示信息里，平均值不会大于10ms。
util是磁盘利用率，20%表示有1s内有80%的时间磁盘是空闲的。100%表示磁盘繁忙，满负荷运行。
如图：服务器上运行redis，由于redis进程会在key change后fork rdb子进程来持久化内存数据，所以写操作会突然出现一个很高的峰值。
但由于rdb子进程是非连续性的，一般几十秒就操作完毕进程消失了，然后await迅速回落。所以当采样周期为1s，会发现虽然await和util很高。但拉长采样周期，就还好。
所以这个数据是健康的。
如图：是一台日志集中存储服务器，await是持续大于100ms，util也是持续100%。这样，io就会阻塞并丢失数据。
这个数据说明磁盘不行了，要么换ssd，要么使用多节点分散io压力。
3.3 iotop
iotop -oP（only show processes or threads actually doing I/O， only show processes, not all threads）
iotop -p pid（监控一个进程）
如图：是3.2中运行redis的服务器，磁盘写入会在短时间内飙高，但又很快回落。
3.4 disk usage
在3.1的案例中，业务服务器上会产生大量日志，日志信息很庞大。
如图，在业务高峰期，50GB多到0，只花了3个多小时。然后剩余量为0持续了坑爹的2小时，期间日志写入必然失败。直到日志压缩定时任务启动才开始释放空间。
