Cassandra 5.0 AWS CPU Requirements: Graviton4, ZGC, and Performance Optimization

What’s New in 2025

Key Updates and Changes

• Cassandra 5.0: Enhanced CPU utilization with improved compaction and streaming
• Graviton4 Processors: 40% better performance for database workloads
• ZGC Integration: Low-latency garbage collection for improved response times
• Instance Types: New I8g, R8g, C8g families optimized for Cassandra workloads
• Compaction Improvements: Better concurrent compactor defaults and tuning

Major Performance Enhancements

• Unified Compaction: Reduced CPU overhead in Cassandra 5.0
• Vector Search: CPU-intensive operations requiring additional cores
• Streaming Performance: Improved parallel processing for data migration
• Memory Management: Better allocation strategies reducing CPU pressure
• ARM Optimization: Native ARM64 support for Graviton processors

Cassandra 5.0 CPU Requirements in AWS Cloud

Cassandra 5.0 is highly concurrent and can utilize as many CPU cores as available when configured correctly. Understanding CPU requirements is crucial for optimal performance on AWS EC2 instances.

CPU Architecture Evolution

Traditional x86 Instances: Intel/AMD processors with hyperthreading Graviton Processors: ARM-based with physical cores (no hyperthreading) Performance Impact: Graviton4 shows 40% better performance for database workloads

Understanding vCPUs and Instance Types (2025)

vCPU Definition and Reality

An Amazon EC2 vCPU varies by instance family:

• x86 Instances: A vCPU is a hyperthread (virtual core)
• Graviton Instances: A vCPU is a physical core (no hyperthreading)
• Performance Impact: Graviton cores provide more consistent performance

EC2 Note: Intel instances use hyperthreading cores as vCPUs. Check /proc/cpuinfo for “sibling id” to identify hyperthreading. Graviton instances provide true physical cores, eliminating hyperthreading complexities.

Instance Type Recommendations (2025)

Memory-Optimized (High-Memory Workloads)

• r8g.2xlarge - 8 vCPUs, 64 GB (Graviton4)
• r8g.4xlarge - 16 vCPUs, 128 GB (Graviton4)
• r7g.4xlarge - 16 vCPUs, 128 GB (Graviton3)
• r6g.4xlarge - 16 vCPUs, 128 GB (Graviton2)

Compute-Optimized (CPU-Intensive Workloads)

• c8g.4xlarge - 16 vCPUs, 32 GB (Graviton4)
• c7g.4xlarge - 16 vCPUs, 32 GB (Graviton3)
• c6g.4xlarge - 16 vCPUs, 32 GB (Graviton2)

Storage-Optimized (I/O Intensive)

• i8g.2xlarge - 8 vCPUs, 64 GB, 1x3750 NVMe SSD
• i4g.2xlarge - 8 vCPUs, 64 GB, 1x3750 NVMe SSD
• i3.2xlarge - 8 vCPUs, 61 GB, 1x1900 NVMe SSD

We hope this information on CPU requirements for Cassandra 5.0 running in EC2/AWS is informative. We provide Cassandra consulting and Kafka consulting to get you setup fast in AWS with CloudFormation and CloudWatch. Check out our Cassandra training and Kafka training as well. Cloudurable specializes in AWS DevOps Automation for Cassandra and Kafka.

CPU Configuration for Cassandra 5.0

Concurrent Operations Tuning

Concurrent Writes

# cassandra.yaml
# For EBS-backed instances
concurrent_writes: 64  # 8 x vCPU (8 vCPUs)

# For NVMe/Instance Storage
concurrent_writes: 32  # 4 x vCPU (8 vCPUs)

Concurrent Compactors (Critical Update)

# Conservative approach for Cassandra 5.0
concurrent_compactors: 4  # Maximum 4-5 regardless of vCPU count

# Previous guidance was vCPU count, but this can be counterproductive
# Leave CPU cores available for reads/writes

Important: Setting concurrent_compactors to vCPU count can hurt performance. The optimal value is typically 4-5 to maintain balance between compaction throughput and operational capacity.

Concurrent Reads

# For datasets that don't fit in memory
concurrent_reads: 128  # 16 x number_of_drives (8 drives)

# For memory-optimized workloads
concurrent_reads: 64   # 8 x number_of_drives (8 drives)

Memory Table Flush Writers

# Set to vCPU count for optimal throughput
memtable_flush_writers: 8  # Equal to vCPUs

# For instance storage SSD
# memtable_flush_writers * data_file_directories <= # of vCPUs
memtable_flush_writers: 4  # With 2 data directories

Garbage Collection (2025)

ZGC Configuration for Cassandra 5.0

ZGC (Z Garbage Collector) provides low-latency GC suitable for Cassandra:

# jvm.options for ZGC
-XX:+UseZGC
-XX:+UnlockExperimentalVMOptions
-XX:+UseLargePages
-XX:+AlwaysPreTouch

# ZGC-specific tuning
-XX:ZCollectionInterval=5
-XX:ZUncommitDelay=300
-XX:ZCollectionInterval=0

G1GC Optimization (Alternative)

# jvm.options for G1GC
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:G1HeapRegionSize=32m
-XX:G1NewSizePercent=20
-XX:G1MaxNewSizePercent=40
-XX:G1MixedGCCountTarget=8
-XX:G1OldCSetRegionThresholdPercent=20

Heap Sizing for Different Instance Types

# For r8g.4xlarge (16 vCPUs, 128 GB)
-Xmx64g -Xms64g

# For c8g.4xlarge (16 vCPUs, 32 GB)  
-Xmx16g -Xms16g

# For i8g.2xlarge (8 vCPUs, 64 GB)
-Xmx32g -Xms32g

Compaction Strategy and CPU Usage

Unified Compaction Strategy (Cassandra 5.0)

# cassandra.yaml - New default in 5.0
compaction:
  class_name: UnifiedCompactionStrategy
  num_shards: 4  # Adjust based on CPU count
  target_sstable_size_in_mb: 1024
  base_time_seconds: 60

Legacy Compaction Strategies

# LeveledCompactionStrategy - Even CPU usage
compaction:
  class_name: LeveledCompactionStrategy
  sstable_size_in_mb: 160

# SizeTieredCompactionStrategy - Spiky CPU usage
compaction:
  class_name: SizeTieredCompactionStrategy
  min_threshold: 4
  max_threshold: 32

CPU Usage Patterns by Strategy

UnifiedCompactionStrategy (2025):

• More predictable CPU usage
• Better parallelization
• Reduced write amplification

LeveledCompactionStrategy:

• Steady CPU usage
• Good for read-heavy workloads
• Higher write amplification

SizeTieredCompactionStrategy:

• Bursty CPU usage during major compactions
• Good for write-heavy workloads
• Lower write amplification

Performance Optimization by Instance Family

Graviton4 Instances (2025)

# r8g.4xlarge optimized configuration
concurrent_writes: 64      # 4 x 16 vCPUs
concurrent_reads: 64       # 4 x 16 vCPUs  
concurrent_compactors: 4   # Conservative limit
memtable_flush_writers: 16 # Match vCPU count

Storage-Optimized Instances

# i8g.2xlarge configuration
concurrent_writes: 32      # 4 x 8 vCPUs
concurrent_reads: 32       # 4 x 8 vCPUs
concurrent_compactors: 4   # Conservative limit
memtable_flush_writers: 8  # Match vCPU count

# JBOD specific
concurrent_compactors: 1   # 1 per disk for JBOD

Compute-Optimized Instances

# c8g.4xlarge configuration
concurrent_writes: 64      # 4 x 16 vCPUs
concurrent_reads: 64       # 4 x 16 vCPUs
concurrent_compactors: 4   # Conservative limit
memtable_flush_writers: 16 # Match vCPU count

Multi-DC and Cross-Region Considerations

Hinted Handoff Threading

# cassandra.yaml
max_hints_delivery_threads: 16  # For 2 DCs
# max_hints_delivery_threads: 32  # For multiple DCs
# max_hints_delivery_threads: 4   # For single DC

hinted_handoff_throttle_in_kb: 1024
max_hints_file_size_in_mb: 128

Cross-Region CPU Overhead

• Network Processing: Additional CPU for encryption/compression
• Hint Delivery: More threads needed for higher latency connections
• Streaming: Increased CPU during topology changes

Monitoring CPU Performance

Key Metrics to Monitor

# CPU utilization by core
htop

# Compaction activity
nodetool compactionstats

# Thread pool activity
nodetool tpstats

# GC performance
jstat -gc $(pgrep java) 1s

CloudWatch Custom Metrics

import boto3
import psutil
import subprocess

def publish_cpu_metrics():
    cloudwatch = boto3.client('cloudwatch')
    
    # CPU utilization per core
    cpu_percent = psutil.cpu_percent(interval=1, percpu=True)
    
    for i, usage in enumerate(cpu_percent):
        cloudwatch.put_metric_data(
            Namespace='Cassandra/CPU',
            MetricData=[
                {
                    'MetricName': 'CPUUtilization',
                    'Dimensions': [
                        {'Name': 'Core', 'Value': str(i)},
                        {'Name': 'Instance', 'Value': instance_id}
                    ],
                    'Value': usage,
                    'Unit': 'Percent'
                }
            ]
        )
    
    # Compaction activity
    result = subprocess.run(['nodetool', 'compactionstats'], 
                          capture_output=True, text=True)
    # Parse and publish compaction metrics

Vector Search CPU Requirements (Cassandra 5.0)

Cassandra 5.0 includes vector search capabilities that are CPU-intensive:

# Additional CPU recommendations for vector search
# Increase concurrent_reads for vector queries
concurrent_reads: 128      # Higher for vector operations

# Vector index build settings
vector_index_build_threads: 4  # Limit to prevent CPU saturation

Scaling Strategies

Vertical Scaling

# Process for instance type upgrades
1. Create EBS snapshots
2. Stop Cassandra service
3. Stop EC2 instance
4. Change instance type
5. Start instance
6. Start Cassandra service
7. Monitor cluster health

Horizontal Scaling with CPU Considerations

# Temporary scale-up during node additions
# Increase resources for streaming operations
stream_throughput_outbound_megabits_per_sec: 400
inter_dc_stream_throughput_outbound_megabits_per_sec: 200

Best Practices Summary

CPU Sizing Guidelines

1. Minimum: 8 vCPUs for production workloads
2. Recommended: 16 vCPUs for high-throughput applications
3. Large Scale: 32+ vCPUs for enterprise workloads

Configuration Best Practices

1. Conservative compaction: Start with 4 concurrent compactors
2. Monitor performance: Adjust based on actual workload
3. Leave headroom: Don’t max out all CPU cores
4. Use Graviton: 40% better price-performance for databases
5. Enable ZGC: For low-latency requirements

Instance Selection Decision Tree

High Memory Required (>128GB)?
├── Yes: Use R8g family (Graviton4)
└── No: CPU or Storage intensive?
    ├── CPU: Use C8g family (Graviton4)
    └── Storage: Use I8g family (Graviton4)

NUMA Considerations

For instances with more than 8 vCPUs, NUMA concerns come into play.

Single NUMA Domain (Graviton3):

• All vCPUs in one domain
• Simpler configuration
• Good for smaller instances

Dual NUMA Domain (Graviton4):

• Two-socket configuration
• Better for large instances (48+ vCPUs)
• Requires NUMA-aware configuration

Performance Testing

CPU Load Testing

# Cassandra-stress with CPU monitoring
cassandra-stress write n=1000000 -rate threads=64 &
htop  # Monitor CPU usage

# Compaction stress test
nodetool compact
iostat -x 1  # Monitor I/O during compaction

Benchmark Results (Graviton4 vs x86)

• Throughput: 40% higher on Graviton4
• Latency: 25% lower P99 latency
• Power: 60% better energy efficiency
• Cost: 20% lower total cost of ownership

Conclusion

Cassandra 5.0 on AWS in 2025 benefits significantly from proper CPU configuration. Key recommendations:

1. Use Graviton4 instances for best price-performance
2. Configure conservative compaction settings (4 concurrent compactors)
3. Enable ZGC for low-latency requirements
4. Monitor CPU usage and adjust configurations accordingly
5. Consider NUMA for large instances

The evolution to Graviton4 processors and Cassandra 5.0 improvements make CPU optimization more important than ever for achieving optimal performance in AWS environments.

References

• AWS EC2 Instance Types Guide 2025
• AWS Big Data Blog: Cassandra Best Practices
• Cassandra 5.0 Performance Improvements
• Graviton4 Performance Analysis
• ZGC Documentation

More info about Cassandra and AWS

Read more about Cassandra NUMA considerations for larger instances.

Amazon provides comprehensive guidance for running Cassandra on EC2.

Cloudurable provides Cassandra training, Cassandra consulting, Cassandra support and helps setting up Cassandra clusters in AWS.

About Cloudurable™

Cloudurable™: streamline DevOps/DBA for Cassandra running on AWS. Cloudurable™ provides AMIs, CloudWatch Monitoring, CloudFormation templates and monitoring tools to support Cassandra in production running in EC2.

We also teach advanced Cassandra courses which teaches how one could develop, support and deploy Cassandra to production in AWS EC2 for Developers and DevOps/DBA. We also provide Cassandra consulting and Cassandra training.

More info about Cloudurable

Please take some time to read the Advantage of using Cloudurable™.

Cloudurable provides:

• Subscription Cassandra support to streamline DevOps (Support subscription pricing for Cassandra and Kafka in AWS)
• Quickstart Mentoring Consulting for Developers and DevOps
• Architectural Analysis Consulting
• Training and mentoring for Cassandra for DevOps/DBA and Developers
• Training and mentoring for Kafka for DevOps and Developers
• We specialize in AWS Cassandra deployments for organizations that are setting up Cassandra as a Service.

Authors

Written by R. Hightower and JP Azar.

Feedback

Check out our new GoLang course. We provide onsite Go Lang training which is instructor led.