0

在 Opscenter 中，我看到其中一个节点是橙色的。似乎它正在压缩。我使用了nodetool compactionstats，每当我这样做时，已完成的百分比保持不变（即使中间有几个小时）。我目前在该节点上看不到来自 cassandra 的 cpu 负载。所以它似乎卡住了（60％左右）。其他一些节点也对同一列族进行了压缩。我没有看到任何进展。

编辑：突然之间，我再次看到了变化。然而进展并没有上去。它来自 +60%，现在为 50.95%。所以看起来压缩重新开始了。EDIT2：似乎它实际上突然完成了，我混淆了 2 个类似命名的列族。EDIT3：完成在另一个似乎也卡住的节点上。其中一个节点仍处于这种“卡住”状态，已耗尽并且不使用 cpu for java。

 WARN [RMI TCP Connection(554)-192.168.0.68] 2015-11-09 17:18:13,677 ColumnFamilyStore.java (line 2101) Unable to cancel in-progress compactions for usage_record_ptd.  Probably there is an unusually large row in progress somewhere.  It is also possible that buggy code left some sstables compacting after it was done with them
  • 我怎么能保证什么都没有发生？
  • 是否建议禁用特定数据大小的压缩？（我相信每个节点有 25GB）。
  • 我可以停止这种压缩吗？nodetool 停止压缩似乎不起作用。
  • 停止压实是否危险？
  • 压缩时杀死 cassandra 进程是否危险（我确实在一个节点上耗尽了 nodetool）？

还有什么注意事项吗？提前非常感谢！

这是 nodetool compactionstats 的输出，为似乎卡住的键空间进行了 grepped。

4e48f940-86c6-11e5-96be-dd3c9e46ec74     mykeyspace            mycolumnfamily             1447062197972             52321301       16743606       {1:2, 4:248}
94acec50-86c8-11e5-96be-dd3c9e46ec74     mykeyspace            mycolumnfamily             1447063175061             48992375       13420862       {3:3, 4:245}
3210c9b0-8707-11e5-96be-dd3c9e46ec74     mykeyspace            mycolumnfamily             1447090067915             52763216       17732003       {1:2, 4:248}
24f96fe0-86ce-11e5-96be-dd3c9e46ec74     mykeyspace            mycolumnfamily             1447065564638             44909171       17029440       {1:2, 3:39, 4:209}
06d58370-86ef-11e5-96be-dd3c9e46ec74     mykeyspace            mycolumnfamily             1447079687463             53570365       17873962       {1:2, 3:2, 4:246}
f7aa5fa0-86c7-11e5-96be-dd3c9e46ec74     mykeyspace            mycolumnfamily             1447062911642             47701016       13291915       {3:2, 4:246}
806a4380-86f7-11e5-96be-dd3c9e46ec74     mykeyspace            mycolumnfamily             1447083327416             52644411       17363023       {1:2, 2:1, 4:247}
c845b900-86c5-11e5-96be-dd3c9e46ec74     mykeyspace            mycolumnfamily             1447061973136             48944530       16698191       {1:2, 3:6, 4:242}
bb44a0b0-8718-11e5-96be-dd3c9e46ec74     mykeyspace            mycolumnfamily             1447097599547             48768463       13518523       {2:2, 3:5, 4:242}
f2c17ea0-86c3-11e5-96be-dd3c9e46ec74     mykeyspace            mycolumnfamily             1447061185418             90367799       13904914       {5:4, 6:7, 7:52, 8:185}
1aae6590-86ce-11e5-96be-dd3c9e46ec74     mykeyspace            mycolumnfamily             1447065547369             53190698       17228121       {1:2, 4:248}
d7ca8d00-86d5-11e5-96be-dd3c9e46ec74     mykeyspace            mycolumnfamily             1447068871120             52422499       16995963       {1:2, 3:3, 4:245}
6e890290-86df-11e5-96be-dd3c9e46ec74     mykeyspace            mycolumnfamily             1447072989497             45218168       17174468       {1:2, 3:21, 4:227}

我在 system.log 中也经常看到这样的行：

WARN [Native-Transport-Requests:11935] 2015-11-09 20:10:41,886 BatchStatement.java (line 223) Batch of prepared statements for [billing.usage_record_by_billing_period, billing.metric] is of size 53086, exceeding specified threshold of 5120 by 47966.
4

0 回答 0