CTOP is a tool which allows you to quickly find out what's happening on a machine running Cassandra. It is particularly useful on a cluster with multiple-tenants, multiple-applications, and large numbers of tables. If you suspect that the performance is not good, then you can use this to figure out which table is giving you trouble.

• Download a DEB file from the releases section
• Install mx4j "apt-get install libmx4j-java"
• Install CTOP "dpkg -i ctop_1.3_amd64.deb"
• Find out what's killing your Cassandra cluster

• Download a binary (or compile one yourself)
• Install mx4j jars in the java/cassandra classpath (download from here)
• Re-start cassandra
• Run CTOP

• Run the binary
• Allow CTOP some time to collect metrics, then press SPACE to refresh the display. You will see your tables listed by Reads/s (in descending order).
• You can press SPACE at any time to refresh the display
• The numbers 1 through 5 change the sorting order: 1: Order by Reads/s 2: Order by Writes/s 3: Order by the amount of disk-space used (in Bytes) 4: Order by read-latency (in miliseconds) 5: Order by write-latency (in miliseconds)
• Pressing "Q" will quit
• Metrics are for one node only (not cluster-wide)

• CTOP should run on anything. Originally was developed on Ubuntu, and it's reported to run on CentOS and MacOS X.

• CTOP uses "libmx4j-java" (an HTTP -> JMX) to retrieve JMX metrics from Cassandra (there was no easy way to query JMX directly), so this needs to be in the class-path where Cassandra can find it upon startup (with Ubuntu it is enough to do "apt-get install libmx4j-java", then to re-start Cassandra).
• Cassandra needs to be told how to run MX4J (the default is to listen to the interface that Cassandra listens on):

  MX4J_ADDRESS="-Dmx4jaddress=127.0.0.1"  
  MX4J_PORT="-Dmx4jport=8081"  
  JVM_OPTS="$JVM_OPTS $MX4J_ADDRESS"  
  JVM_OPTS="$JVM_OPTS $MX4J_PORT"