CPU利用率
[root@host ~]# cat /proc/cpuinfo |grep "processor"|wc -l
4
查看本机的核心数
最常用CPU监测工具是TOP,当然TOP输出是一个瞬间值,如果想获取精确的数据,需要持续关注一段时间。
[root@host ~]# top
top - 13:52:48 up 58 days, 4:48, 4 users, load average: 0.00, 0.00, 0.00
Tasks: 139 total, 1 running, 138 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2%us, 0.1%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 3867260k total, 3762552k used, 104708k free, 16368k buffers
Swap: 8191992k total, 2787096k used, 5404896k free, 75704k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9924 root 20 0 2849m 62m 5028 S 0.3 1.7 16:52.53 java
10367 root 20 0 2779m 157m 5916 S 0.3 4.2 9:32.92 java
26374 root 20 0 4721m 409m 6404 S 0.3 10.8 2:28.76 java
27826 root 20 0 15032 1352 1008 R 0.3 0.0 0:00.08 top
1 root 20 0 19232 496 364 S 0.0 0.0 0:00.55 init
.......................
TOP的使用主要看两个值,其一是总体使用值,其最大值是100%, 第三行Cpu(s),前面0.2%,0.1%分别是用户态和内核态的利用率,而99.8%是CPU空闲率,从这个可以看出,本机的CPU部分基本是空闲的;其二可以看相关进程,看它的“%CPU”使用率,比如,PID为9924这个进程的占用率是0.3%,但是这里面的100%不是本机所有CPU的100%,而是单个核的100%。所以它的上限会是本机核数*100%。
内存的监测
[root@host ~]# free -m
total used free shared buffers cached
Mem: 3776 3641 135 0 14 72
-/+ buffers/cache: 3554 222
Swap: 7999 2745 5254
关于内存的监测,常用的命令是free -m,通过这个命令可以查看系统内存的具体使用情况。其中total,used和free都很好理解,通过这三列可以看出此时系统总内存,已经使用内存和没有被使用的内存,而cached这列则表示有多少内存已经被Page Cache占用,但当系统内存吃紧的时候,Page Cache会立即被回收并分配给请求内存的应用程序,所以Page Cache也可以被视为处于free状态的内存。
还有下面的Swap分区,如果used数值比较高,说明内存非常紧张,系统已经动用交换区,同时IO开销也会增长非常明显。当发现内存不够用的情况,可以考虑重启或者关闭那些占
用很多内存的进程。
I/O性能的监测
[root@host ~]# iostat –xz 1
Linux 2.6.32-431.el6.x86_64 (host) 2018年08月23日 _x86_64_ (4 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle 0.31 0.00 0.19 0.28 0.00 99.22
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
avg-cpu: %user %nice %system %iowait %steal %idle 0.25 0.00 0.00 0.00 0.00 99.75
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
avg-cpu: %user %nice %system %iowait %steal %idle 0.25 0.00 0.25 2.24 0.00 97.26
关于I/O性能,可以通过iostat这个命令来观察I/O的性能,(sda是主硬盘),虽然参数比较多,但可以主要关注这两个参数:
其一是await,它代表了IO操作的平均等待时间,单位是毫秒,这也是应用和磁盘之间操作所要消耗的时间,包括等待和实际的操作,如果这个数值大,说明I/O资源非常忙或者有故障;
其二是%util,也就是设备利用率,数值如果超过60,所以利用率很高,并会影响I/O平均等待时间,如果到100,那就说明设备已饱和了,只能添加更多I/O资源。
网络方面的监测
安装sar
yum -y install sysstat
[root@host ~]# sar -n DEV 1 2
Linux 2.6.32-431.el6.x86_64 (host) 2018年08月23日 _x86_64_ (4 CPU)
14时50分48秒 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
14时50分49秒 lo 18.00 18.00 2.09 2.09 0.00 0.00 0.00
14时50分49秒 eth0 1.00 1.00 0.06 0.17 0.00 0.00 0.00
14时50分49秒 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
14时50分50秒 lo 9.00 9.00 0.75 0.75 0.00 0.00 0.00
14时50分50秒 eth0 1.00 1.00 0.06 0.37 0.00 0.00 0.00
平均时间: IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
平均时间: lo 13.50 13.50 1.42 1.42 0.00 0.00 0.00
平均时间: eth0 1.00 1.00 0.06 0.27 0.00 0.00 0.00
代码方面的优化
写入优化,传统关系数据库的写入是一行一行的写入,而常见大数据产品的写入是批量的写入,并且每次批量写入之后,都会生成新的数据文件,并且这个数据文件是不会被修改的。所以导入数据粒度小的话会导致很多细小文件产生,这样会导致更多的I/O操作,所以在使用大数据产品的时候,导入数据规模是越大越好,常见的规模在100MB以上为佳。
尽可能并行,尽可能地通过并行来提升性能,主要有两个方式:其一是每台机器上面部署更多的进程来压榨硬件资源;其二是提升单个进程的多线程数,这种方式比第一种更简单,风险也更低。总体而言,尽量使每台机器所使用到的线程数可以达到系统自身线程数的80%。
尽可能的压缩和列存
合理使用分区
join的优化, 小表可以使用广播