【 使用环境 】生产环境
【 OB or 其他组件 】OMS
【 使用版本 】4.2.13
【问题描述】
OMS创建任务的时候，【增量同步】和【反向增量】在选择默认的【平稳、正常、快速】配置的时候，只设置并发度，并没有同时设置JVM内存，一直是2~4GB，但是【全量校验、全量迁移】选择的时候JVM内存就会跟着并发度改变，这应该是BUG吧？不然我要是选了快速，32并发但是JVM2~4GB，运行没多久就会FULL GC了
OMS创建任务的时候，【增量同步】和【反向增量】在选择默认的【平稳、正常、快速】配置的时候，只设置并发度，并没有同时设置JVM内存，一直是2~4GB，但是【全量校验、全量迁移】选择的时候JVM内存就会跟着并发度改变，这应该是BUG吧？不然我要是选了快速，32并发但是JVM2~4GB，运行没多久就会FULL GC了
2 个赞
设计符合预期的 增量不会主动改内存的 增量正常情况下内存不像全量那样需求那么大
我生产的长期增量同步任务之前碰到过时不时的延迟很高，然后排查下来是并发高，JVM太低了，然后一直full gc导致的延迟。32并发配2~4G肯定是搭不上的把
目前的设计 确实是这样设计的 增量组件的内存 确实是需要不高 如果有full gc的情况 建议是增加内存
好吧，我只是提个建议，你们确认是预期内的就行
也感谢你的建议 内部也是有考虑过的
大佬，再请教个问题。
我在模拟mysql迁移ob的流程。这个step4《确认源端停写》在生产上肯定是我等开发全部通知我已经停写，或者我在mysql侧把账号全部禁用/回收写权限之类的，确认好了我才会去点step4里的“确认”，然后点好了以后呢step5里会检测正向同步的延迟，但如果这一步稍微操作慢了点（我不知道检测设定的阈值是多少，先假定1分钟），这里就会显示延迟，但是延迟的实际原因是源头没写入了，增量拉不到变更，然后延迟就越来越大，永远结束不了。我现在想到的方法是在增量里加一个我自定义的心跳表，等step4我“确认”完之后，step5在检测延迟了，我再写入一条数据进去，他拉到增量同步完延迟就会归零然后step5的检测延迟才会通过，才能继续走下去。这一步有什么官方的推荐做法吗？
这个跟真实的业务停写没联动吧，要自己把控流程
你这么说也是可以的，就变成了我这里主动发起账号禁用/权限回收之类的，这个没问题，但依旧避免不了后面的1分钟延迟检测问题。我比方说把账号rename掉了，kill连接肯定也要观察一会儿的，确认没新链接进来了才证明OK，这个耗时肯定不止1分钟的，然后等我确认完，下一步就进入这个检测延迟的死循环了
dd
1 个赞