!- Zendesk tag -->
This document describes how to catch large partitions.
Any of the following:
Latencies on a single shard become very long (look at the “Scylla 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: PK[/CK[/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"
nodetool cfstats demodb.tmcr | grep "Compacted partition maximum bytes" Compacted partition maximum bytes: 1188716932
Starting from scylla 2.3, large partitions are listed in the
system.large_partitions table. See Scylla Large Partitions Table for more information.
Starting from scylla 3.1, large rows and large cells are listed similarly in the
system.large_cells tables, respectively. See Scylla 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.