大数据运维问题记录(七)

问题描述:公司中一个项目我们用netty接收厂商提供的数据入kafka，接收速度较慢，入kafka也比较慢，需要对其进行一些优化。
问题解决:利用一周左右的时间对其代码和相关配置进行了一些优化，并测试了一下性能，现将测试过程和结果分析进行总结。
一.测试环境

测试节点描述.png

1.服务端主机配置如下表：

服务端主机配置.png
2.Kafka服务器配置如下表：
kafka主机配置.png
二.测试需求/目标
在客户端40个并发的情况下，获得服务端运行时的相关数据，从而进行分析，对服务端进行优化，使得客户端数据没有积压并提高服务端系统的稳定性。

三.测试内容
本次测试包括两步，第一步测试仅接收客户端数据并解析不入kafka的性能，第二步测试接收客户端数据解析后实时入kafka的性能。
四.测试结果及分析
此次由于客户端的原因，测试吞吐量有限，所以并未真正达到测试的极限目的。
以下是客户端的吞吐量

客户端吞吐量.png
在测试仅接收客户端数据时出现程序运行一段时间后出现频繁fullgc最后导致出现内存溢出,gc内存不够的情况。服务端接收的数据包逐渐减少，客户端出现积压，分析程序后一方面业务逻辑那块因为是通过字节传输的需要进行解码后拼接成需要的字符串，所以这块会影响一部分性能，以下是业务逻辑的复杂度：
业务逻辑处理种类.png
在调整优化业务逻辑代码后，最后总结出以下几个netty的优化配置项:
bossGroup此项是负责处理客户端的连接请求，并将accept的连接注册到workerGroup的其中一个线程上，因为TCP连接的三次握手I/O频繁，使用一个独立的bossGroup线程池可以提升性能。所以这块设置为1。
workerGroup此项负责处理客户端通道上的数据读写，因为服务端的服务器逻辑cpu数是32个也就是最大线程并发数是32，并且没有其它业务在此服务器上部署，所以这块设置为32。
SO_BACKLOG此项用于构造服务端套接字ServerSocket对象，标识当服务器请求处理线程全满时，用于临时存放已完成三次握手的请求的队列的最大长度。这块设置为128。
EventExecutorGroup此项是设置独立的业务逻辑线程池，因为业务逻辑中解析数据比较费时，所以要显示的指定业务逻辑线程池，从而可以让workGroup及时处理其它客户端的请求。所以这块也设置为32。
另外对程序中的变量和对象进行优化，能不实例化的就不要实例化，并且将程序中的无用日志去掉。
netty最终的参数配置如下表：
netty最终参数.png
优化完后重新运行，运行平稳没有频繁出现fullgc的情况，并且cpu负载也较稳定，客户端也没有积压

以下是netty接收的数据量：

netty服务端接收数据量.png
cpu负载情况如下图：
cpu负载1.png
接下来测试数据接收过来解析完后入kafka的性能时出现频繁fullgc，并且入kafka的速度也很慢，客户端出现数据积压的情况。因为之前测试了不入kafka的情况，所以这块不是netty处理的问题，需要优化入kafka的程序和相关配置(注意配置参数，不同的kafka版本会有所不同)我们的kafka是0.90版本，kafka producer中影响性能的配置主要有以下几个：
acks：这个配置可以设定发送消息后是否需要Broker端返回确认，设置为0不需要进行确认
batch.size：Producer会尝试去把发往同一个Partition的多个Requests进行合并，指明了一次Batch合并后Requests总大小的上限。
linger.ms：Producer默认会把两次发送时间间隔内收集到的所有Requests进行一次聚合然后再发送，以此提高吞吐量，而linger.ms则更进一步，这个参数为每次发送增加一些delay，以此来聚合更多的Message
buffer.memory：在Producer端用来存放尚未发送出去的Message的缓冲区大小。
在测试过程中我们发现不是一味的增加batch size的大小或者增大linger.ms的大小或者增大buffer.memory的值可以加快发送到kafka的效率，需要根据实际的数据传输速率进行不断的调整优化，最终我们将batch size的值设置为500000，linger.ms的值设置为200，buffer.memory的值设置为默认值33554432后可以满足客户端数据不积压，入kafka的效率达到稳定，同时cpu负载也达到稳定，gc也达到稳定。同时为了防止客户端发送数据突然出现陡增，我们加大了 jvm的内存参数为-Xms50g -Xmx50g(默认为30g)。
kafka的最终配置如下表：
kafka最终配置图.png
以下是运行平稳后发送到kafka的速率:
入kafka效率.png
cpu的负载情况：
cpu负载2.png
gc的运行情况:
gc运行情况图.png
五.总结
采用netty架构只要对相应的参数进行调试，可以满足目前的业务数据请求，运行效率比较稳定。后续数据如果出现陡增，一方面要继续对各项参数进行调整外，还可以采用netty集群的方式进行解决。不管是netty的参数还是kafka的参数都没有一个固定值，都需要根据服务器本身的配置以及具体的业务和数据进行不断调试，从而达到性能稳定的效果。