福哥答案2020-08-16：
一 问题背景
项目中遇到大数据任务执行时间比较长，需要进行优化，使得大数据的任务执行时间优化至客户可以接受的时间。
二 原因分析
l 业务场景分析
本场景下的大数据任务主要对数据进行mapreduce操作，该任务包含两个子任务，第一个子任务的map（每个map的大小为128M）个数为4300左右（这些map任务都是分散在不同的服务器上，TaiShan集群有6400+个核可以处理,可以充分利用TaiShan多核优势），map执行时间为10分钟，但是reduce个数固定写为200个（即最多有200个核并行处理reduce任务），reduce执行时间为1小时30分钟左右,耗时较长，同时reduce个数相比map个数很少，不能充分利用TaiShan多核优势，第二个子任务也是reduce阶段耗时较长
l 服务器基础性能分析
在大数据任务执行时，cpu利用率不高，磁盘io以及网卡IO都没有瓶颈，不过网卡中断需要进行绑核，同时磁盘缓存参数可以进行调优来提升性能
三 解决方案
3.1 网卡调优
3.1.1 中断绑核
中断亲和度描述为可以为特定中断提供响应的一组CPU，如果应用程序可以通过关联到相关的CPU，在相同的CPU上下文中处理接收到的数据包，则可以减少等待时间，提高CPU利用率。
因此，我们可以将处理网卡中断的CPU core设置在网卡所在的NUMA上，从而减少跨NUMA的内存访问所带来的额外开销，提升网络处理性能。
3.2 磁盘参数调优
3.2.1 磁盘读预取参数
/sys/block/sdX/queue/read_ahead，这个参数对顺序读非常有用，意思是，一次提前读多少内容，无论实际需要多少。默认一次读 128kb 远小于要读的，设置大些对读大文件非常有用，可以有效的减少读 seek 的次数，这个参数可以使用 blockdev –setra 来设置，setra 设置的是多少个扇区，所以实际的字节是除以2，比如设置 512 ，实际是读 256 个字节.
原服务器值是128kb， 设置为4096Kb。
3.2.2 缓存写入磁盘参数调整
/proc/sys/vm/dirty_ratio 从20改成40
这个参数控制文件系统的文件系统写缓冲区的大小，单位是百分比，表示系统内存的百分比，表示当写缓冲使用到系统内存多少的时候，开始向磁盘写出数据。增大之会使用更多系统内存用于磁盘写缓冲，也可以极大提高系统的写性能。
/proc/sys/vm/dirty_background_ratio 从10改为20
这个参数控制文件系统的pdflush进程，在何时刷新磁盘。单位是百分比，表示系统内存的百分比，意思是当写缓冲使用到系统内存多少的时候，pdflush开始向磁盘写出数据。
增大之会使用更多系统内存用于磁盘写缓冲，也可以极大提高系统的写性能。
/proc/sys/vm/dirty_writeback_centisecs 从500改为800
这个参数控制内核的脏数据刷新进程pdflush的运行间隔。单位是 1/100 秒。缺省数值是500，也就是 5 秒
/proc/sys/vm/dirty_expire_centisecs 从3000改为30000
这个参数声明Linux内核写缓冲区里面的数据多“旧”了之后，pdflush进程就开始考虑写到磁盘中去。单位是 1/100秒。缺省是 30000，也就是 30 秒的数据就算旧了，将会刷新磁盘。
对于特别重载的写操作来说，这个值适当缩小也是好的，但也不能缩小太多，因为缩小太多也会导致IO提高太快
3.3 应用程序调优
3.3.1 Reduce个数优化
在大数据平台调整reduce设置，使最大reduce个数从原来的200改为500，性能提升明显
3.3.2 Reduce并行copy参数maprd.reduce.parallel.copies优化
Reduce的并发拷贝数默认是5，后来调整至30可以提升reduce的最大并发拷贝数
经过调优，最终大数据任务执行时间有明显提升
四总结
调优后，TaiShan集群服务器上任务执行时间有明显改善。对相关思路总结如下：
l 分析确认大数据任务执行时各个阶段的耗时，重点分析耗时阶段，提升reduce并发，充分利用TaiShan多核优势。
l 明确性能瓶颈，并对服务器各个子模块进行参数调优。
来源：oschina
链接：https://my.oschina.net/u/4375296/blog/4503322