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

问题描述:公司中一个项目我们用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的参数都没有一个固定值,都需要根据服务器本身的配置以及具体的业务和数据进行不断调试,从而达到性能稳定的效果。
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,884评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,347评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,435评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,509评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,611评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,837评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,987评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,730评论 0 267
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,194评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,525评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,664评论 1 340
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,334评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,944评论 3 313
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,764评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,997评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,389评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,554评论 2 349

推荐阅读更多精彩内容