oms数据同步的时候是单线程拉还是并发拉变更日志？

刘彻 · 2023 年12 月 20 日 19:36

cms

yixingqingkong · 2023 年12 月 20 日 19:50

好的，了解了，感谢解答！最后再确认下如果大事务导致的话相当于并不是数据同步真正有延迟，而是因为位点提交有延时所以导致从管理端看到是有延迟的假象？

fuwarren · 2023 年12 月 20 日 19:59

看起来没有full gc。

刘彻 · 2023 年12 月 20 日 20:03

可以在writer的配置source中添加
useSchemaCache=true
useBetaListener=true

fuwarren · 2023 年12 月 20 日 20:39

嗯嗯，我加下试试。我看最高的时候sink用满了，但是ready batch为0，需要增加sink的数量么？

这个workNum具体指的啥，不知道在哪里看，请指点！

刘彻 · 2023 年12 月 21 日 09:46

ready_execute_batch_size为0，应该是瓶颈不在wokernum上，瓶颈一般是在读取

fuwarren · 2023 年12 月 21 日 11:01

从oms自带的监控上来看，store拉取应该没啥问题，Incr_Sync比较慢，这个是有中间缓存么？

yixingqingkong · 2023 年12 月 21 日 11:01

SINK_THREAD：当前活跃 sinkThread / 最大 sinkThread。如果 sinkThread 较少证明 sink 端较为空闲，未达到瓶颈。
请问这个最大 sinkThread的值能调大吗？活跃的数量已经达到最大，应该怎么调呢？是不是这个就是workerNum？

fuwarren · 2023 年12 月 21 日 11:11

还有个问题：文档上说如果 wait record 数量较多，证明消息数量较大，可能受到 GC 影响。延迟较高的时候，wait record都在400多，但是后面的ParNew(count：3155，cost：18969)，ConcurrentMarkSweep(count:0, cost:0)这个应该是只有yong gc，没有full gc，这个yong gc次数这么高对性能有没有影响？

fuwarren · 2023 年12 月 21 日 11:15

如果最后一个队列 batchAccumulate 满则证明瓶颈在 RecordDispatcher(冲突矩阵/散列) 中，此时需要看 DISPATCHER 的 metrics，看延迟比较高的时候queue_slot1 batchAccumulate: 32, recordAccumulate: 800，是DISPATCHER这里有瓶颈么？文档上好像没写怎么查看dispatcher的日志，在docker内部logs目录下也没有找到