---
id: f0d557e3-5666-4e98-aa09-3ed0564e3b33
---

# Slow Query Performance on Cassandra Cluster.
---

This incident type refers to a situation where there is a significant delay in the execution of queries on a Cassandra cluster. This delay can cause the system to become unresponsive and result in slower performance. It may be caused by a variety of factors such as an increase in traffic, inefficient queries, or hardware issues. The issue can impact the functionality of the system and requires immediate attention to prevent further disruption.

### Parameters
```shell
export PATH_TO_CONFIG_FILE="PLACEHOLDER"
```

## Debug

### Check Cassandra cluster status
```shell
nodetool status
```

### Check if any node is down
```shell
nodetool status | grep -v 'UN'
```

### Check Cassandra cluster load
```shell
nodetool info | grep Load
```

### Check Cassandra cluster compaction history
```shell
nodetool compactionhistory
```

### Check slow queries in Cassandra
```shell
nodetool tpstats | grep "Slow"
```

### Check Cassandra cluster status
```shell
nodetool status
```

### Check if any node is down
```shell
nodetool status | grep -v 'UN'
```

### Check Cassandra cluster load
```shell
nodetool info | grep Load
```

### Check Cassandra cluster compaction history
```shell
nodetool compactionhistory
```

### Check slow queries in Cassandra
```shell
nodetool tpstats | grep "Slow"
```

## Repair

### Check the Cassandra database configuration and ensure that it is properly optimized for the workload it handles. For instance, you may need to increase the size of the read/write buffers, cache, and threads.
```shell


#!/bin/bash



# Set the configuration file path

CONFIG_FILE=${PATH_TO_CONFIG_FILE}



# Increase the read/write buffers

sed -i 's/read_request_timeout_in_ms:.*/read_request_timeout_in_ms: 10000/' $CONFIG_FILE

sed -i 's/write_request_timeout_in_ms:.*/write_request_timeout_in_ms: 10000/' $CONFIG_FILE



# Increase the cache size

sed -i 's/row_cache_size_in_mb:.*/row_cache_size_in_mb: 1024/' $CONFIG_FILE



# Increase the number of threads

sed -i 's/concurrent_reads:.*/concurrent_reads: 64/' $CONFIG_FILE

sed -i 's/concurrent_writes:.*/concurrent_writes: 64/' $CONFIG_FILE



# Restart Cassandra service

systemctl restart cassandra


```

This incident type refers to a situation where there is a significant delay in the execution of queries on a Cassandra cluster. This delay can cause the system to become unresponsive and result in slower performance. It may be caused by a variety of factors such as an increase in traffic, inefficient queries, or hardware issues. The issue can impact the functionality of the system and requires immediate attention to prevent further disruption.


This incident type refers to an elevated time spent on processing queries in an Elasticsearch cluster. It could be an indication of potential resource bottlenecks or a need to optimize the queries. This incident requires investigation and resolution to prevent further issues and ensure a smooth functioning Elasticsearch cluster.


High time spent on Elasticsearch queries

This incident type refers to a problem in a Cassandra cluster where the token range imbalances cause uneven distribution of data across the cluster. This can result in slower read and write performance that can impact the overall functionality of the system. Token range imbalances occur when the distribution of the tokens that define the ranges of data each node is responsible for is not evenly spread across the cluster. As a result, certain nodes may be responsible for a disproportionate amount of data, leading to performance issues and potential failure of the system.


Token Range Imbalances Causing Uneven Data Distribution and Performance Issues in Cassandra Cluster

This incident type relates to identifying slow running queries on the Cassandra database and determining the users responsible for running them. Slow queries can cause performance issues and impact the overall efficiency of the system. Identifying and troubleshooting slow queries is crucial for maintaining optimal performance and ensuring smooth operations of the database. The incident may require investigating the root cause of the slow queries, optimizing the database configuration and queries, and providing recommendations to mitigate future incidents.


Slow Running Queries on Cassandra

In this incident type, there is an issue with a Cassandra cluster where one or more disks are running slow. This can cause performance issues and potentially lead to data loss or downtime. The goal is to identify and address the specific disk(s) causing the problem in order to restore normal cluster operations.


Slow Disk in Cassandra Cluster

This incident type refers to a situation where a delay or slowness occurs in a system that uses Cassandra database due to the shared storage. Shared storage means multiple servers are accessing the same storage unit, and this can cause latency issues. This type of incident can lead to performance degradation, and it needs to be addressed promptly to ensure optimal system performance.


Latency Caused by Shared Storage in Cassandra

```shell
export PATH_TO_CONFIG_FILE="PLACEHOLDER"
```


### Check Cassandra cluster status

```shell
nodetool status
```

### Check if any node is down

```shell
nodetool status | grep -v 'UN'
```

### Check Cassandra cluster load

```shell
nodetool info | grep Load
```

### Check Cassandra cluster compaction history

```shell
nodetool compactionhistory
```

### Check slow queries in Cassandra

```shell
nodetool tpstats | grep "Slow"
```

### Check Cassandra cluster status

```shell
nodetool status
```

### Check if any node is down

```shell
nodetool status | grep -v 'UN'
```

### Check Cassandra cluster load

```shell
nodetool info | grep Load
```

### Check Cassandra cluster compaction history

```shell
nodetool compactionhistory
```

### Check slow queries in Cassandra

```shell
nodetool tpstats | grep "Slow"
```


### Check the Cassandra database configuration and ensure that it is properly optimized for the workload it handles. For instance, you may need to increase the size of the read/write buffers, cache, and threads.

```shell


#!/bin/bash



# Set the configuration file path

CONFIG_FILE=${PATH_TO_CONFIG_FILE}



# Increase the read/write buffers

sed -i 's/read_request_timeout_in_ms:.*/read_request_timeout_in_ms: 10000/' $CONFIG_FILE

sed -i 's/write_request_timeout_in_ms:.*/write_request_timeout_in_ms: 10000/' $CONFIG_FILE



# Increase the cache size

sed -i 's/row_cache_size_in_mb:.*/row_cache_size_in_mb: 1024/' $CONFIG_FILE



# Increase the number of threads

sed -i 's/concurrent_reads:.*/concurrent_reads: 64/' $CONFIG_FILE

sed -i 's/concurrent_writes:.*/concurrent_writes: 64/' $CONFIG_FILE



# Restart Cassandra service

systemctl restart cassandra


```


Slow Query Performance on Cassandra Cluster.

Overview

Parameters

Debug

Check Cassandra cluster status

Check if any node is down

Check Cassandra cluster load

Check Cassandra cluster compaction history

Check slow queries in Cassandra

Check Cassandra cluster status

Check if any node is down

Check Cassandra cluster load

Check Cassandra cluster compaction history

Check slow queries in Cassandra

Repair

Check the Cassandra database configuration and ensure that it is properly optimized for the workload it handles. For instance, you may need to increase the size of the read/write buffers, cache, and threads.

Learn more

Related Runbooks

High time spent on Elasticsearch queries

Token Range Imbalances Causing Uneven Data Distribution and Performance Issues in Cassandra Cluster

Slow Running Queries on Cassandra

Slow Disk in Cassandra Cluster

Support