V1.1.9.4版本发布

ydb.1.1.9.4性能调优总结

之前在某场景下,原有的YDB在跨越多个分区的情况下性能表现不佳,主要表现在并发较低,但机器CPU与磁盘均比较空闲,资源没有利用起来.

折腾一个星期的YDB跨越多个分区的并发查询总算告一段落.

以下是我在测试环境 90个分区 128并发查询 在调优过程中几个有效的方法.

,网络由socket aio变更为netty nio 网络并发性能提升 30%

先前一直纠结在这里,浪费了较多的时间,但是提升也就是那么一点点.

,log4j将日志更改为error级别,并发性能提升 50%以上

之后考虑异步IO,查询分区越多,记录的日志多,影响特别明显

,修正hiveoperate log BUG,并禁掉,整体性能提升60%

这个日志根本就用不上,会在本地磁盘记录很多文件,但是HIVEBUG,我们进行了修正,需要更换YDB最新版本的spark

,调整程序内关键流程的同步机制,由锁更换为atomic的方式 整体性能提升90%

关键点,锁的性能跟操作系统实现有关,对性能影响很大,这几天深入了解了下系统的锁的原理,持有方式,还是少用为好

而我们系统大部分的地方都可以更换为atomic的方式, 第一次同步的使用用锁初始化,以后都通过atomic直接访问

,hadopPath,String,Exception等拼字符串的操作优化,能重用就重用 GC时间减少 性能提升40%

字符串连接太耗CPU,不要随便new excption(之前为了一些日志,但是打印堆栈是有代价的)

,程序内部分对象用了finalizer进行回收和重用,更改为try{}finally{}的方式 GC时间减少 性能提升45%

不得不承认 这个方法 YGC影响非常大

,YDB自带timeout线程池会对执行超时的线程进行kill处理,由于查询逻辑执行的特别快,短期内执行队列堆积太快,判断超时的线程检查逻辑会成为瓶颈,查询分区越多,堆积越快,这也是为何跨越越多的分区,查询性能越慢,修正后 直接性能 在之前优化的基础上在提升50%

BUG,之前的设计缺陷,之前设计初衷是为了防止创建索引 hdfs BUG或者其他IO很高的情况下 某个线程一直不结束,YDB能进行发现并预警,如果长久不结束 也可以kill掉这个线程,但是对高并发的情况下没有考虑,这次针对高并发这里做了特别优化,会及时清理掉.

,JVM GC参数进行了优化,参数优化提升空间有限 提升空间不到10% ,但上述7点做完后,YGC的时间由600ms缩减到50ms