硬件性能调优

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小时，期间日志写入必然失败。直到日志压缩定时任务启动才开始释放空间。