Har*_*rry 2 cassandra cassandra-3.0
我有一台提交日志不断增加到7.8 GB并仍在增长的机器,我检查了commitlog_total_space_in_mb: 8192在cassandra.yaml中注释的属性。我怀疑它一定是默认值。
1)提交日志大小增加有什么问题?
2)是否说我的记忆力尚未达到?
编辑:
memtable_cleanup_threshold = 1 /(memtable_flush_writers + 1)*(memtable_offheap_space_in_mb + memtable_heap_space_in_mb)
推荐值在哪里
memtable_flush_writers - Smaller of number of disks or number of cores with a minimum of 2 and a maximum of 8, so in our case it is '8'
memtable_offheap_space_in_mb - 1/4 of the heap size, so in our case it is 2GB
memtable_heap_space_in_mb - 1/4 of the heap size, so in our case it is 2GB
Run Code Online (Sandbox Code Playgroud)
因此计算将
memtable_cleanup_threshold = 1/(8 + 1) * 4096
memtable_cleanup_threshold = 455MB
Run Code Online (Sandbox Code Playgroud)
为什么没有刷新到455 MB并删除提交日志?
是的,默认值为8192MB(或日志文件磁盘空间的1/4,以较小者为准;如果服务器较小,则可能适用)。来源:有关commitlog_total_space_in_mb的Cassandra文档。
要回答您的问题:
(1)如果commitlog文件继续增长,则磁盘空间可能用完。
(2)尚未达到配置的阈值。
在您添加其他问题后进行编辑以添加:
刷新内存表时不会删除Commitlog。
请注意,文件大小是根据您的配置大小预先分配的-我想您已经知道了,但是请注意,如果其他人尝试通过ls或类似方法观察文件大小。
如果您nodetool drain或重新启动,它们将被清除。否则,它们将继续增长到最大大小并旋转。
这是一个测试,查看如果强制执行刷新会发生什么:
nodetool tablestats keyspace.table | grep "Memtable data size"
Memtable data size: 1292049
cat /var/lib/cassandra/commitlog/CommitLog-A.log | wc -l
10418
cat /var/lib/cassandra/commitlog/CommitLog-B.log | wc -l
0
nodetool flush
nodetool tablestats keyspace.table | grep "Memtable data size"
Memtable data size: 0
cat /var/lib/cassandra/commitlog/CommitLog-A.log | wc -l
10419
cat /var/lib/cassandra/commitlog/CommitLog-B.log | wc -l
0
nodetool drain
nodetool tablestats keyspace.table | grep "Memtable data size"
Memtable data size: 0
cat /var/lib/cassandra/commitlog/CommitLog-A.log | wc -l
no such file
cat /var/lib/cassandra/commitlog/CommitLog-B.log | wc -l
0
Run Code Online (Sandbox Code Playgroud)
如果它基于内存表配置自动刷新,则会看到类似的结果。在以下观察到的所有刷新中,也不清除提交日志:
| 归档时间: |
|
| 查看次数: |
379 次 |
| 最近记录: |