为啥新环境的Kafka性能这么差？

本故事纯属虚构，如有雷同，纯属巧合，一笑了之。
公司分配给了A和B一个任务，测试容器化Kafka集群的性能。之前B在老机器上已经测试过一个版本，并写了完整的报告，算是有经验的老鸟了。
现在到了一批新机器，需要在它们上面重新测试一下Kafka的性能，A主动承担这个该任务，要知道新机器不管从cpu核数还是内存大小都是老机器的两倍，而且新机器用的是SSD盘，而老机器用的是机械盘。
A信心满满，认认真真地按照之前B写的文档操作。可测试结果让他大吃一惊，新机器的性能竟然不到老机器的一半。

网络问题？

A：这个Kafka集群压测数据怎么这么差？会不会是网络问题呢？
B：之前我们用的是万M网卡，你这个是多少？
A：网卡速度怎么看？
B：用ethtool命令，后面加对应的网络接口名，看Speed值，就能知道是万M还是千M网卡了。

$ ethtool eth0
Settings for em0:
Supported ports: [ TP ]
...
Speed: 1000Mb/s
...

A：这是千M网卡，怪不得性能会这么差呢。
B：你确定是网卡的问题吗？你压测的时候用nload命令查看一下网络的带宽有没有跑满。
A：nload?这个怎么用？
B：nload命令使用非常简单，后面加对应网络接口名就能查看网卡的出入流量了。

$ nload eth0

nload命令结果

A：离跑满还远着呢。那应该不是网卡带宽的问题了。

容器问题

A：我想会不会跟容器相关呀？容器的SDN什么的那么复杂，又加包头，解包头，会不会对Kafka有影响了呀？
B：你直接搭一个单机版的Kafka运行在一台主机上，不做容器化，就在那台机器上测试，不走网络看下性能如何。
A：Good Idea！
半小时后
A：性能还是没上去，看来可以排除容器和网络的因素了。

磁盘问题？

A：那磁盘呢，Kafka数据可是会落盘的，压测时磁盘的IO应该比较大吧？
B：我们之前测的时候使用的是机械盘接SAS口，8k的写能达到200M/s。你测下你的IO是多少。
A：怎么测？
B：磁盘的IO简单测试使用dd命令就可以，测试写时记得添加oflag=direct，要更仔细测试就使用用fio命令。

dd

time dd if=/dev/zero of=test.dbf bs=8k count=300000 oflag=direct #测试写性能
$ dd if=test.dbf bs=8k count=300000 of=/dev/null  #测试读性能

fio

$ #4k顺序写
$ for dep in {1,2,4,8,16,32,64,128};do fio -filename=/dev/vdb --ioengine=libaio -direct=1 -rw=write -bs=4k -size=50G -iodepth=$dep -group_reporting -ramp_time=10 -runtime=60 -name=model_4K_${dep}_100SAS_seq_write --output=/home/model_4K_${dep}_100SAS_seq_write.log -numjobs=1; done

$ #4k顺序读
$ for dep in {1,2,4,8,16,32,64,128};do fio -filename=/dev/vdb --ioengine=libaio -direct=1 -rw=read -bs=4k -size=50G -iodepth=$dep -group_reporting -ramp_time=10 -runtime=60 -name=model_4K_${dep}_100SAS_seq_read --output=/home/model_4K_${dep}_100SAS_seq_read.log -numjobs=1; done

$ #4k随机写
$ for dep in {1,2,4,8,16,32,64,128};do fio -filename=/dev/vdb --ioengine=libaio -direct=1 -rw=randwrite -bs=4k -size=50G -iodepth=$dep -group_reporting -ramp_time=10 -runtime=60 -name=model_4K_${dep}_100SAS_rand_write --output=/home/model_4K_${dep}_100SAS_rand_write.log -numjobs=1; done

$ #4k随机读
$ for dep in {1,2,4,8,16,32,64,128};do fio -filename=/dev/vdb --ioengine=libaio -direct=1 -rw=randread -bs=4k -size=50G -iodepth=$dep -group_reporting -ramp_time=10 -runtime=60 -name=model_4K_${dep}_100SAS_rand_read --output=/home/model_4K_${dep}_100SAS_rand_read.log -numjobs=1; done

$ #4k混合顺序读写
$ for dep in {1,2,4,8,16,32};do fio -filename=/dev/vdb --ioengine=psync -direct=1 -rw=readwrite -bs=4k -size=100G -iodepth=$dep -group_reporting -ramp_time=30 -runtime=120 -name=model_4K_${dep}_100SAS_seq_read_write --output=/home/model_4K_${dep}_100SAS_seq_read_write.log -numjobs=1; done

$ #4k混合随机读写
$ for dep in {1,2,4,8,16,32};do fio -filename=/dev/vdb --ioengine=psync -direct=1 -rw=randrw -bs=4k -size=100G -iodepth=$dep -group_reporting -ramp_time=30 -runtime=120 -name=model_4K_${dep}_100SAS_rand_read_write --output=/home/model_4K_${dep}_100SAS_rand_read_write.log -numjobs=1; done

A：结果出来了，性能好差，写才70M/s，算下来IOPS才8000左右，之前环境IOPS有20000多呢。看来这个磁盘性能真的有问题呀。
B：你确认下它是不是SSD盘，部署机器的C跟我说挂载的是SSD盘。
A：肯定不是呀，这么差。我到机房去看一看吧。
B：不用去机房，你查看下系统的磁盘参数/sys/block/*/queue/rotational，如果是0的话就是SSD。

$ grep ^ /sys/block/*/queue/rotational

A：竟然值是0，那这么差的盘竟然是SSD！别当我无知就好欺负呀。我去机房拔下来看。
半小时后
A：上面挂载的还真是SSD盘，但接的是SATA口。
B：磁盘性能并不只跟磁盘有关，跟接口的关系也非常大，PCIE卡>SAS>SATA，如果有做Raid的话，性能也会有不一样。PCIE卡不能做Raid。
A：怪不得，那现在是磁盘有问题？
B：你可以在压测的时候看下磁盘的实时IOPS是多少。
A：怎么看？
B：用iostat命令，后面可以接需要观察的盘符名，看结果中的w/s，与r/s值就能知道实时的IOPS了。

$ iostat /dev/vdb -x 1

A：结果显示这两个值都很低呀，最高不到1000，有的时候才几十，远远没有到瓶颈呀。
B：要排除磁盘问题，你还可以不用磁盘，直接把内存挂载到对应的目录下，再压测，看结果有没有变化。
A：把内存挂载到对应目录？这个又是么高科技？（抓头）
B：不算什么高科技，其实很简单啦。linux系统的目录/dev/shm是在内存上，你把kafka的数据目录指向这个目录下就好了。

linux系统的目录/dev/shm是在内存上

A：这样呀，我测试下。。。性能还是很低呀。
B：嗯，又排除了磁盘的影响。

系统问题？

A：我想会不会是系统的配置问题？之前环境用的是rh 7.3，而这次我们装的是rh 7.5。
B：那给现在这台机器重装下系统，使用同样的rh 7.3，再压测下试试。
A：好，就这么干。
半个小时后
A：测试结果出来了，还是很低呀。并没有任何改进。
B：看来跟系统也没有关系。

CPU问题？

B：我们看下CPU的信息。查看/proc/cpuinfo能查看cpu的详情。

$ cat /proc/cpuinfo
......
model name  : Intel(R) Xeon(R) Gold 6138 CPU @ 2.00GHZ
cpu MHz     : 1995.381
...

A：原先主机的CPU频率我也查到了，3.00GHZ，整整大了50%
B：现在两个环境系统是完全一样的，我们可以使用计算圆周率的办法测下单核cpu的能力。
A：计算圆周率，我要去研究下算法了。（抓头）
B：不用，使用bc命令直接计算圆周率。

$ time echo "scale=5000;4*a(1)" | bc -l -q

A：好吧。（一会后）新机器计算花了80s，而老机器才18s，差距这么大！
B：最后我们用unixbench工具对主机性能做下全面测试，看看结果如何。
A：unixbench？怎么又来了个新工具。。。这个怎么测？
B：unixbench测试非常简单，它不仅能测试单核性能，还可以测试多核性能。代码在https://github.com/kdlucas/byte-unixbench，直接运行Run就可以了。

$ Run
......
80 CPUs in system; running 1 parallel copies of tests

System Benchmarks Index Score                                        4678.5
......
80 CPUs in system; running 80 parallel copies of tests

System Benchmarks Index Score                                        8820.4

一个小时后
A：终于运行好了，新的机器测试的分数连之前机器分数的一半都不到。这不是逗我吗，测的可是新机器呀！
......
A：到底是哪有问题呀？！我找厂商去。

评价：把问题死磕到底，你会有非常多的收获。