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的优化， 小表可以使用广播