nodetool sjk
Invokes the Swiss Java Knife (SJK) diagnostic tool for JVM troubleshooting and performance analysis.
Synopsis
Section titled “Synopsis”nodetool [connection_options] sjk [--] <args>See connection options for connection options.
Arguments:
| Argument | Description |
|---|---|
-- | Optional separator to distinguish nodetool options from SJK arguments |
<args> | Arguments passed verbatim to Swiss Java Knife |
The -- separator is useful when SJK arguments might be mistaken for nodetool options.
Description
Section titled “Description”nodetool sjk provides access to Swiss Java Knife (SJK), a collection of command-line tools for JVM diagnostics, monitoring, and profiling.
Background
Section titled “Background”SJK was integrated into Cassandra nodetool via CASSANDRA-12197. This integration allows operators to perform JVM diagnostics directly through nodetool without needing to install separate tools or manage additional JAR files on Cassandra nodes.
How It Works
Section titled “How It Works”When nodetool sjk is invoked:
- Nodetool establishes a JMX connection to the target Cassandra node using standard nodetool connection options (
-h,-p,-u,-pw) - The SJK arguments are passed to the embedded SJK library
- SJK commands that require JVM access use the JMX connection and process ID provided by nodetool
- Results are returned to the console
Connection Handling
Cassandra's nodetool integration manages the JMX connection. SJK's own connection options (--pid, --socket, etc.) are not available through nodetool sjk. The connection is always established through nodetool's standard mechanism.
Getting Help
Section titled “Getting Help”To see available SJK commands for the installed Cassandra version:
# List all available commandsnodetool sjk --commands
# Get general helpnodetool sjk --help
# Get help for a specific commandnodetool sjk <command> --helpVersion-Specific Commands
The available commands and their options depend on the SJK version bundled with the Cassandra distribution. Always use nodetool sjk --commands to see what is available in the current environment.
Common Commands
Section titled “Common Commands”The following commands are typically available. Run nodetool sjk --commands to confirm availability and nodetool sjk <command> --help for exact option names.
ttop - Thread CPU Usage
Section titled “ttop - Thread CPU Usage”Displays JVM threads sorted by CPU usage, similar to the Linux top command but for threads within a single JVM process.
# Show thread CPU usagenodetool sjk ttop
# Show top N threads (check --help for exact option name)nodetool sjk ttop --helpUse cases:
- Identify threads consuming excessive CPU
- Detect runaway compaction or streaming threads
- Find threads blocked in contention
- Monitor allocation rates to diagnose GC pressure
hh - Heap Histogram
Section titled “hh - Heap Histogram”Prints a histogram of objects on the heap, similar to jmap -histo. This is useful for identifying memory leaks or unexpected object retention.
Stop-the-World Pause
The heap histogram operation may cause a stop-the-world pause. Some options require a full garbage collection. Use with caution on production systems.
# Show heap histogramnodetool sjk hh
# Show top N classes with live objects onlynodetool sjk -- hh --top-number 20 --live
# Get help for available optionsnodetool sjk hh --helpUse cases:
- Identify classes with unexpectedly high instance counts
- Detect memory leaks (growing instance counts over time)
- Analyze object retention patterns
- Compare live vs dead objects to understand allocation patterns
gc - Garbage Collection Tracker
Section titled “gc - Garbage Collection Tracker”Reports garbage collection statistics in real time.
# Monitor GC activitynodetool sjk gc
# Get available optionsnodetool sjk gc --helpUse cases:
- Monitor GC behavior under load
- Detect long GC pauses affecting latency
- Verify GC tuning changes
- Correlate GC activity with application performance
stcap - Stack Trace Capture
Section titled “stcap - Stack Trace Capture”Captures thread stack traces at regular intervals for profiling and analysis.
# Capture stack traces (check --help for options)nodetool sjk stcap --help
# Example: capture to file for specified durationnodetool sjk -- stcap --output /tmp/stacks.std --timeout 30000Use cases:
- Profile CPU-intensive operations
- Identify hot code paths
- Analyze thread behavior over time
- Create data for flame graph generation
ssa - Stack Trace Analyzer
Section titled “ssa - Stack Trace Analyzer”Analyzes stack trace files created by stcap.
# Analyze captured filenodetool sjk -- ssa --file /tmp/stacks.std --help
# Generate histogramnodetool sjk -- ssa --file /tmp/stacks.std --histomx - MBean Operations
Section titled “mx - MBean Operations”Queries and invokes JMX MBean operations.
# Get help for MBean operationsnodetool sjk mx --help
# Example: list MBean infonodetool sjk -- mx --bean "java.lang:type=Memory" --infoPractical Examples
Section titled “Practical Examples”Diagnosing High CPU Usage
Section titled “Diagnosing High CPU Usage”# Step 1: Identify which threads are using CPUnodetool sjk ttop
# Step 2: If specific threads are high, capture stack tracesnodetool sjk -- stcap --output /tmp/high-cpu.std --timeout 60000
# Step 3: Analyze the captured datanodetool sjk -- ssa --file /tmp/high-cpu.std --histoInvestigating Memory Issues
Section titled “Investigating Memory Issues”# Step 1: Get heap histogramnodetool sjk -- hh --top-number 30
# Step 2: Check for live objects only (triggers GC)nodetool sjk -- hh --top-number 30 --live
# Step 3: Monitor GC behaviornodetool sjk gcCollecting Diagnostic Data
Section titled “Collecting Diagnostic Data”# Create diagnostic directorymkdir -p /tmp/cassandra-diag
# Capture thread CPU usagenodetool sjk ttop > /tmp/cassandra-diag/ttop.txt
# Capture heap histogramnodetool sjk -- hh --top-number 50 > /tmp/cassandra-diag/heap.txt
# Capture stack traces for 60 secondsnodetool sjk -- stcap --output /tmp/cassandra-diag/stacks.std --timeout 60000Common Cassandra Thread Patterns
Section titled “Common Cassandra Thread Patterns”When analyzing thread output, these patterns indicate Cassandra-specific activity:
| Thread Name Pattern | Purpose |
|---|---|
ReadStage-* | Processing read requests |
MutationStage-* | Processing write requests |
CompactionExecutor-* | Running compactions |
MemtableFlushWriter-* | Flushing memtables |
GossipStage-* | Cluster gossip protocol |
Native-Transport-* | CQL client connections |
HintsDispatcher-* | Delivering stored hints |
Best Practices
Section titled “Best Practices”Production Usage
Section titled “Production Usage”- Use
ttopandgcfreely—they have minimal overhead - Use
hhsparingly as it may cause stop-the-world pauses - Capture stack traces (
stcap) during off-peak hours when possible - Always check
--helpfor exact option names before scripting
Using the Separator
Section titled “Using the Separator”When SJK options conflict with nodetool parsing, use -- to separate them:
# Without separator (may cause parsing issues)nodetool sjk hh --top-number 10
# With separator (explicit argument passing)nodetool sjk -- hh --top-number 10Troubleshooting
Section titled “Troubleshooting”Command Not Recognized
Section titled “Command Not Recognized”If a command is not recognized, verify it is available:
nodetool sjk --commandsConnection Issues
Section titled “Connection Issues”SJK commands use the nodetool JMX connection. If commands fail:
# Verify nodetool connectivity firstnodetool status
# Check JMX settingsgrep JMX /etc/cassandra/cassandra-env.shOption Errors
Section titled “Option Errors”Option names may vary between SJK versions. Always check:
nodetool sjk <command> --helpRelated Commands
Section titled “Related Commands”| Command | Relationship |
|---|---|
| tpstats | Thread pool statistics (Cassandra-specific) |
| gcstats | GC statistics (Cassandra-specific format) |
| info | General node information including memory |
| tablestats | Table-level metrics |
External Resources
Section titled “External Resources”- SJK GitHub Repository - Source code and documentation
- CASSANDRA-12197 - Integration ticket