flink sql主要涉及到9张mysql表（snapshot+cdc）,任务的解析后的算子较多，大概60~70个，但主要是join，和4~5个GroupAggregate算子，最后sink，sink不是瓶颈已经排除。
恩，已经调过几版参数了我的机型的配置是一样的，12核+24G内存 + ssd 50G，共6台（任务并行度设置为60，除去了flink mysql cdc流的并行度为1，其它算子并行度都为60） taskmgr的flink-conf主要参数为，其它为默认： taskmanager.numberOfTaskSlots: 10 taskmanager.memory.process.size: 20480m taskmanager.memory.managed.fraction: 0.75 taskmanager.memory.network.fraction: 0.2 taskmanager.memory.network.max: 4gb #算子大概需要3G左右的network buf taskmanager.memory.network.min: 128mb #13G state.backend.rocksdb.thread.num: 4 state.backend.rocksdb.writebuffer.count: 48 state.backend.rocksdb.writebuffer.size: 256M #12G state.backend.rocksdb.writebuffer.number-to-merge: 1 state.backend.rocksdb.block.cache-size: 2000M #2112M state.backend.rocksdb.block.blocksize: 64K state.backend.rocksdb.localdir: /opt/flink/rocksdb state.backend.rocksdb.files.open: 90000 这一板算是比较好的一版，但依然感觉比较慢。观察性能，6台的性能差异不大，都差不多,也没看到明显的数据倾斜。 起始阶段大部分数据都是写状态，启动阶段来看，是速率输入最快的时刻，后面越来越慢，慢慢的source算子就出现反压了。 观察一小时的数据如下，1小时后，每张表平均能跑个500w左右的数据，从观察来看，cpu在等待时间较大，但load又比较重，10核也就能跑个5核左右。硬盘的io也没到ssd的瓶颈，状态大小跑1个小时后，每台机器ssd硬盘上(state.backend.rocksdb.localdir)的状态大小也是2GB左右。 <http://apache-flink.147419.n8.nabble.com/file/t670/topolo.png> <http://apache-flink.147419.n8.nabble.com/file/t670/dstat.png> <http://apache-flink.147419.n8.nabble.com/file/t670/ssd.png> <http://apache-flink.147419.n8.nabble.com/file/t670/top.png> 这一版本参数里，主要是把state.backend.rocksdb.writebuffer.count调大了，在任务启动的时候，数据基本是都是写，比如把state.backend.rocksdb.writebuffer.count设为10的话，速度就更慢了，io util会到80%左右。 这个参数感觉不是很好调。 尝试用内存跑，5几分钟左右就能把每张表能跑个500w左右的数据跑完，基本没io，cpu都是满状态跑，并且算子是没有反压的，当然任务基本马上也就被oom-kill了，内存不够。 不知道这里有啥优化方法么？@yuntang -- Sent from: http://apache-flink.147419.n8.nabble.com/
