Was this page helpful?
Caution
You're viewing documentation for an unstable version of ScyllaDB Open Source. Switch to the latest stable version.
This document describes how to catch large partitions.
Any of the following:
Latencies on a single shard become very long (look at the “ScyllaDB Overview Metrics” dashboard of ScyllaDB Monitoring Stack).
Oversized allocation warning messages in the log:
seastar_memory - oversized allocation: 2842624 bytes, please report
A warning of “Writing large (partition|row|cell)” is issued when writing to a table (usually happens during a compaction):
WARN 2022-09-22 17:33:11,075 [shard 1]large_data - Writing large partition Some_KS/Some_table: [COL] (SIZE bytes) to SSTABLE_NAME
In this case, refer to Troubleshooting Large Partition Tables for more information.
For each table you suspect run:
nodetool flush <keyspace name> <table name>
nodetool cfstats <keyspace name>.<table name> | grep "Compacted partition maximum bytes"
For example:
nodetool cfstats demodb.tmcr | grep "Compacted partition maximum bytes"
Compacted partition maximum bytes: 1188716932
Large rows and large cells are listed in the system.large_rows
and system.large_cells
tables, respectively. See ScyllaDB Large Rows and Cells Tables for more information.
When compaction or writing to a table results in a “Writing a partition with too many rows” warning:
This warning indicates that there is a huge multi-row partition (based on the number of rows) and it is orthogonal
to the size-based warnings. The warning is controlled by compaction_rows_count_warning_threshold
, which is set in the scylla.yaml.
See Troubleshooting Large Partition Tables for more information.
Was this page helpful?