我就没事闲
(我就没事闲)
1
在确定GC的safepoint时,需要保证safepoint点之前数据没有小于safepoint点的lock以防止commit的primary不被回收,进而保证对应的secondary数据的可决议性。
对于大/长事务,其lock由于一直处于keepalive的保活状态而不会因resolve lock而abort掉。所以safepoint可能一直被这样的事务block在一个较旧的值,进而导致活跃系统版本回收过慢引起性能问题。
请问这方面目前是什么状态?(懒得去看代码直接来发问了)
https://book.tidb.io/session1/chapter6/big-txn-in-4.0.html#63-40-的大事务支持
这个帖子有提到大事务原理,也能看出有一个gc_lifetime,但总觉得没有非常明确地指出这方面的问题。
来了老弟
2
你好,
大事务运行正如你所说不会因为 gc 而清理掉 lock
目前 tidb 不支持手动 gc,所以事务运行这边提供超时 和 事务使用内存限制,当下一个 gc 到来,旧版本就会被清理掉。
我就没事闲
(我就没事闲)
3
了解了,感谢!我也有研究基于Percolator的事务,也有了解TiDB这方面的探索和优化,也在博客做了总结。建议可以考虑一下我提到的优化。因为有些场景可能确实RMW比较频繁,GC如果有时效性问题可能对性能影响很大。
来了老弟
4
多谢对 tidb 的关注,这边反馈给研发,可以将文章发到 asktug 截图中的版块中,这边会关注的~
我就没事闲
(我就没事闲)
7
那啥,解决GC时效性那个方案,已经被dongxu大佬发现问题了。博客中相应内容也更新了哈哈,不过还是贴出来避免踩坑吧。
https://blog.csdn.net/maxlovezyy/article/details/99707690
我就没事闲
(我就没事闲)
9
@户口舟亢-PingCAP 我又想到了解决方案,在博客里也有更新 ,再次推送哈!如果贵司又遇到这样的case可以参考一起讨论下。
system
(system)
关闭
11
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。