从文档中给出了
commitlog_total_space_in_mb（默认值：32位JVM的32MB，8192MB，用于64位JVM）注意提交库中使用的总空间。如果二手空间超过了此值，则Cassandra将其转到下一个最近的段，并将模拟物的磁盘融合到最古老的Commitlog段的磁盘，从而删除了这些日志段。这减少了在启动时重播的数据量，并防止了不频繁的表格，从而无限期地保留commitlog段。较小的总提交量空间往往会在较小的表上引起更多的冲洗活动。
，从cassandra.yaml中指定：
用于磁盘上的提交日志的总空间。
如果空间超过此值，Cassandra将冲洗每一个肮脏的CF在最古老的细分市场中并删除它。所以总的commitlog空间很小在不太活跃的柱子上会倾向于引起更多的冲洗活动。
默认值是8192的较小值，总空间的1/4commitlog卷。
commitlog_total_space_in_mb：8192
我的查询是以下语句的含义：
默认值是8192的较小值，总空间的1/4commitlog卷。
我在同一硬盘驱动器中有我的commitlog，但是不同的驱动器我将提交日志的数量分配给了70 GB。我应该将其减少到8GB还是应该将其减少到32 GB，因为音量空间的1/4使我考虑了该分区空间。
我有commitlog_total_space_in_mb的默认值，那么理想的提交日志分区大小？
P.S：我知道这2个应该在不同的驱动器上以提高性能。
至于您关于cassandra.yaml语句的第一个问题 - 提交日志大小将是：
Min(8GB, 0.25*total_disk_size)
在您的情况下，由于您已经分配了70 GB，因此提交日志大小为8 GB。您可以避免在Cassandra.yaml
设置大小的计算至于您的第二个问题，从我的测试设置在8GB下的提交日志目录时，最佳尺寸是多少增加该尺寸。