1.业务背景

数据处理链路

• 源端：kafka
• 接入端：ETL
• 处理端1：服务1
• 处理的2：服务2
• 存储端：clickhouse

系统某次升级后，发现数据一直延迟，ETL cpu跑不上去，服务2一直高内存，fullgc并且oom离线。

2.排查过程

2.1 ETL问题排查以及调优

• 将ETL发送到服务1的链路断开，直接丢弃数据，定位ETL性能问题
• 处理链路：kafka -> 拉取线程 -> ringbuffer1 -> Deal线程处理 -> ringbuffer2 -> Send线程
• 发现调大一次拉取的max.poll.records，吞吐量会提升，但是再高就会容易发生oom，吞吐量急剧下降
• 发现Deal线程要么卡在了上游ringbuffer1，此时调大max.poll.records和拉取线程数以及ringbuffer1大小有用
• 发现Deal线程要么卡在了下游ringbuffer2，此时调大Send线程和ringbuffer2大小有用
• 但是调得太大，就会容易发生fullgc和oom
• 最后在拉取线程的地方加了一个操作，对拉取的数据做切分，然后内存就变得可控了，并且参数可调空间就变得很大，性能提升了两倍多

2.2 服务1

• 发现内存一直包超限，并且发送下游一直失败，在重发
• 将内存从3g调整为8g
• 去掉了抽取无用指标
• 指标加了batch processor，进行了打包聚合压缩
• 扩展nginx，并且将8台流量打到新的nginx上，保留老的7台走老的nginx

2.3 服务2

• 服务2一直会发生kafka堆外内存不够，发现堆外内存默认参数1g不合理，直接去掉了
• 通过dump oom发现服务内存占用大头在发送指标的线程上，很多线程持有400M的数据
• 将该线程从100向下调小到50
• 在压测时发现有一个组件被打挂了，然后排查该组件时发现，一直有entitiy.service查询，统计出有600次/s
• 经排查是该组件发起的查询，并且是空值查询
• 处理掉空值查询后，服务正常

2.4 ck-consumer参数调优

针对指定表，调优的处理线程数和攒批大小，提高入库吞吐量。