最近我们插入了数百万条记录并从表中删除了数百万条记录,大小为10 GB的表被截断.
我们使用SizeTieredCompactionStrategy运行2个节点,当前CPU利用率为100%且待定压缩正在增加,当前待定压缩为293144
任何指针都可以降低CPU利用率并快速完成压缩.
降低CPU利用率并快速完成压缩.
这两件事是正交的.您可以加速压缩(通过使用更多资源)或限制压缩的资源,这样您的写入不会受到影响,但需要更长时间.
如果你的cassandra集群有一个摄取运行,我会尽量确保它不受你的压缩影响.只要等待的压缩#随着时间的推移而减少,这只是一个时间问题.
如果您没有读取或写入(IE停机时间或您正在引导),则可以让压缩耗尽所有资源并快速完成.
杠杆是:
1)获取/设置压缩吞吐量(nodetool) - 仅启动下一个可用的压缩.这就是压实发生的速度.如果您有可用资源,则默认值为16 mb/s,您可以将此值增加到更大的数字.
2)并发压缩器 - 您必须在JMX中设置2个值.您可以使用jmxsh或jconsole等动态执行此操作.这是您一次可以运行的压缩次数(核心数).
Watch nodetool compactionstats或OpsCenter(您还可以绘制待定压缩和设置警报)以查找当前压缩或nodetool comactionhistory已完成压缩的进度.
一个大小为10 GB的表被截断.
截断是免费的,不需要压缩.
| 归档时间： |
|
| 查看次数： |
1522 次 |
| 最近记录： |