pika
pika copied to clipboard
请问一下WAL文件和write-buffer-size参数关系
write-buffer-size设置为256M时,WAL文件大小会快速涨到280M左右;write-buffer-size设置为64M时,wal文件只会涨到70几M。但是我的理解应该是wal size > db-write-buffer-size而不应该是write-buffer-size相关,能方便解答下吗?
下面这个是参考网上得到的部分rocksdb信息

WAL文件本质是redo log的,一旦相关的内存信息(write buffer内容)持久化到磁盘(sst文件),那这部分log就可以安全删除了。所以和cf的write buffer size相关。
有关系,但是想知道是什么关系,我记得刘振说过每个slot 5种数据结构会使用10个memtable(rocksdb中一个列簇使用一个。set hash list 使用2个列簇。zset使用3个)。那么每种数据结构的总的memtable大小应该不一样呀,但是结果是每种数据结构的WAL都差不多大
不严格的来讲,可以粗略认为db_write_buffer_size是WAL的上限,write_buffer_size为下限(在未手动设置max_wal_size和flush cf的前提下)。大多数情况下,每个cf的数据量和负载是不一样的,所以同时写满的概率极低。拿咱们的list来说,一个为meta cf,一个为data cf,显然data cf的数据量和负载更大,更容易写满(触发flush,切换WAL)。
不严格的来讲,可以粗略认为db_write_buffer_size是WAL的上限,write_buffet_size为下限(在未手动设置max_wal_size和flush cf的前提下)。大多数情况下,每个cf的数据量和负载是不一样的,所以同时写满的概率极低。拿咱们的list来说,一个为meta cf,一个为data cf,显然data cf的数据量和负载更大,更容易写满(触发flush,切换WAL)。
好的,谢谢
不严格的来讲,可以粗略认为db_write_buffer_size是WAL的上限,write_buffer_size为下限(在未手动设置max_wal_size和flush cf的前提下)。大多数情况下,每个cf的数据量和负载是不一样的,所以同时写满的概率极低。拿咱们的list来说,一个为meta cf,一个为data cf,显然data cf的数据量和负载更大,更容易写满(触发flush,切换WAL)。
您好 想咨询下 我看rocksdb每个cf是有独立的memtable, 但是多个cf共用wal 还是以lists为例,dataCF和metaCF 共用wal, 这种情况下 dataCF应该很容易触发memtable-flush的 但是metaCF却不一定, 这会不会因为MetaCF改动小很久才flush 导致wal迟迟无法删除。 我理解是必须dataCF的memtable和metaCF的memtable都flush了 相关的wal才能被删除的
max_total_wal_size 于2021年11月25日 (周四) 12:02 @.***> 写道:
不严格的来讲,可以粗略认为db_write_buffer_size是WAL的上限,write_buffer_size为下限(在未手动设置max_wal_size和flush cf的前提下)。大多数情况下,每个cf的数据量和负载是不一样的,所以同时写满的概率极低。拿咱们的list来说,一个为meta cf,一个为data cf,显然data cf的数据量和负载更大,更容易写满(触发flush,切换WAL)。
您好 想咨询下 我看rocksdb每个cf是有独立的memtable, 但是多个cf共用wal 还是以lists为例,dataCF和metaCF 共用wal, 这种情况下 dataCF应该很容易触发memtable-flush的 但是metaCF却不一定, 这会不会因为MetaCF改动小很久才flush 导致wal迟迟无法删除。 我理解是必须dataCF的memtable和metaCF的memtable都flush了 相关的wal才能被删除的
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OpenAtomFoundation/pika/issues/980#issuecomment-978808133, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOIBJAHJVJCCEZIIEFWTVDUNWYMHANCNFSM4TMO2SJQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.