pika icon indicating copy to clipboard operation
pika copied to clipboard

请问一下WAL文件和write-buffer-size参数关系

Open AVOlili opened this issue 5 years ago • 6 comments

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

AVOlili avatar Nov 06 '20 09:11 AVOlili

WAL文件本质是redo log的,一旦相关的内存信息(write buffer内容)持久化到磁盘(sst文件),那这部分log就可以安全删除了。所以和cf的write buffer size相关。

LIBA-S avatar Nov 09 '20 04:11 LIBA-S

有关系,但是想知道是什么关系,我记得刘振说过每个slot 5种数据结构会使用10个memtable(rocksdb中一个列簇使用一个。set hash list 使用2个列簇。zset使用3个)。那么每种数据结构的总的memtable大小应该不一样呀,但是结果是每种数据结构的WAL都差不多大

AVOlili avatar Nov 10 '20 01:11 AVOlili

不严格的来讲,可以粗略认为db_write_buffer_size是WAL的上限,write_buffer_size为下限(在未手动设置max_wal_size和flush cf的前提下)。大多数情况下,每个cf的数据量和负载是不一样的,所以同时写满的概率极低。拿咱们的list来说,一个为meta cf,一个为data cf,显然data cf的数据量和负载更大,更容易写满(触发flush,切换WAL)。

LIBA-S avatar Nov 10 '20 02:11 LIBA-S

不严格的来讲,可以粗略认为db_write_buffer_size是WAL的上限,write_buffet_size为下限(在未手动设置max_wal_size和flush cf的前提下)。大多数情况下,每个cf的数据量和负载是不一样的,所以同时写满的概率极低。拿咱们的list来说,一个为meta cf,一个为data cf,显然data cf的数据量和负载更大,更容易写满(触发flush,切换WAL)。

好的,谢谢

AVOlili avatar Nov 10 '20 02:11 AVOlili

不严格的来讲,可以粗略认为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才能被删除的

mzygQAQ avatar Nov 25 '21 04:11 mzygQAQ

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.

yapple avatar Nov 25 '21 05:11 yapple