前言
为了报文传输更小、更快,在HTTP/2中Header头是经过压缩的,使用的压缩算法为HPACK。本文先通过Wireshark抓包截图直观感受下头部压缩效果,进而分析下这种压缩算法是如何工作的。
本文盘点下到Kafka 2.4.1版本以来的一些亮点,这些亮点或笔者实际中踩过的坑、或可能将来会在实践中使用、或个人关注的,点击官方发布日志连接查看全貌。
0.11.0.2于2017年11月17日发布;0.11.0.3于2018年6月2日发布修订版本。
其中修复了0.11.0.2以前的一个BUG,该Bug曾导致过生产事故;即堆内存不能正常回收,频繁Full GC。详见:Kafka(0.11.0.2版本)堆内存不能正常回收问题分析【实战笔记】[KAFKA-6307]
参数的设置通常是一种取舍,看下retries参数在版本0.11.3说明:
1 | Setting a value greater than zero will cause the client to resend |
备注:当发送失败时客户端会进行重试,重试的次数由retries指定,此参数默认设置为0。即:快速失败模式,当发送失败时由客户端来处理后续是否要进行继续发送。如果设置retries大于0而没有设置max.in.flight.requests.per.connection=1则意味着放弃发送消息的顺序性。
1 | 系统相关指标 |
系统信息收
java.lang:type=OperatingSystem
1 | {"freePhysicalMemorySize":"806023168","maxFileDescriptorCount":"4096","openFileDescriptorCount":"283","processCpuLoad":"0.0017562901839817224","systemCpuLoad":"0.014336627412954635","systemLoadAverage":"0.37"} |
Thread信息收集
java.lang:type=Threading
1 | {"peakThreadCount":"88","threadCount":"74"} |
获取mmaped和direct空间
通过BufferPoolMXBean获取used、capacity、count
短信报警堆内存GC后依然超过4G内存,跟上篇文章所说情况相同。只是上次情况告警短信没发出来。这次介入前,dump了该节点的堆照,方便定位引起的问题。
告警GC日志,回收后依然在4G内存,回收前后只减少了几百M。
1 | 2019-05-26T20:41:52.086+0800: 12768164.084: [GC pause (G1 Evacuation Pause) (young), 0.0296753 secs] |
客户端异常报警
晚上10点20分接到使用方电话,日志持续报以下异常,持续时间已有10多分钟。
1 | ERROR 2019-05-15 23:05:23,221 [kafka-producer-network-thread | producer-1] A failure occurred sending a message to Kafka. |