cassandra db的磁盘读/写速率和cpu使用率间歇性地反弹。cassandra是用docker安装的，节点导出器和进程导出器是用来监控的，节点导出器和进程导出器都是用Docker安装的，我在进程导出器反弹的时候查过了，反弹的时候消耗资源最多的进程组名里面有Java，我猜可能是cassandra java有问题。反弹时没有更多的特殊流量进入。它与压缩周期不匹配。群集未被破坏。Cassandra版本为4.0.3
pftdvrlh1#
在Cassandra 4中，你可以通过nodetool访问swiss java knife（sjk），你可以访问的东西之一是ttop.如果你在cpu峰值期间在cassandra env中运行以下命令，你可以看到哪些线程是最大的消费者，然后允许你专门拨入这些线程，看看是否有实际的问题。
nodetool sjk ttop >> $(hostname -i)_ttop.out
让它运行到完成（在报告的高cpu期间），或者如果你决定提前杀死它，至少持续5- 10分钟左右。这将每隔几秒钟收集一次新的迭代，所以一旦完成，解析结果，看看哪些线程是经常的顶级消费者，以及它们实际使用的cpu的百分比，那么您将有一个有针对性的方法，可以在JVM中查找潜在问题。如果没有什么好的结果，接下来进行线程转储以获得更完整的外观，我推荐以下脚本：https://github.com/brendancicchi/collect-thread-dumps
1条答案
按热度按时间pftdvrlh1#
在Cassandra 4中，你可以通过nodetool访问swiss java knife（sjk），你可以访问的东西之一是ttop.如果你在cpu峰值期间在cassandra env中运行以下命令，你可以看到哪些线程是最大的消费者，然后允许你专门拨入这些线程，看看是否有实际的问题。
让它运行到完成（在报告的高cpu期间），或者如果你决定提前杀死它，至少持续5- 10分钟左右。这将每隔几秒钟收集一次新的迭代，所以一旦完成，解析结果，看看哪些线程是经常的顶级消费者，以及它们实际使用的cpu的百分比，那么您将有一个有针对性的方法，可以在JVM中查找潜在问题。
如果没有什么好的结果，接下来进行线程转储以获得更完整的外观，我推荐以下脚本：https://github.com/brendancicchi/collect-thread-dumps