Important
Self-managed SingleStore will soon transition from version 9.1 RC to version 10. This new semantic versioning scheme will provide SingleStore with finer control over engine and feature releases that were not possible with the current versioning scheme.
In the interim, SingleStore 9.1 RC can be used to preview, evaluate, and provide feedback on the new and upcoming features in SingleStore 10 prior to its general availability. Ahead of this transition, SingleStore 9.0 is recommended for production workloads, which can later be upgraded to SingleStore 10.
Reducing Memory Use by Row Store Tables
If rowstore tables are using too much memory there are a few things you can do:
-
Make sure all secondary indexes are actually needed.
They are expensive (40 bytes per row). -
Make sure columns that are actually
NOT NULLare marked asNOT NULL.Some types use an extra 4 bytes per nullable column to store the nullability state of the column (integer types for example). -
Avoid the
CHARdata type.Use VARCHARinstead. -
If the workload is using
DECIMALand doesn’t need fixed point math, useDOUBLEinstead.SingleStore does its best to use the least amount of memory possible for DECIMAL, but a fixed point representation fundamentally needs more storage space then a floating point representation. -
SingleStore’s memory allocators can become fragmented over time (especially if a large table is shrunk dramatically by deleting data randomly).
Use OPTIMIZE TABLE <rowstore table>to compact the table.Warning
Using
OPTIMIZE TABLEwill cause query plans to be rebuilt, so this should not be used that often.Further, the command is resource intensive and for larger tables, can take some time to run. Use caution when running OPTIMIZE TABLE.
If you want more details on how much memory is used by each table, use the following:
-
SHOW TABLE STATUS has a
BuffMgr Memory Usecolumn.This includes memory use for all the components listed above in the rowstore allocator section, but broken down per table. If run on an aggregator, it will show how much memory is used across the entire cluster for the table. If run on a leaf, it will show how much memory the table is using in whichever partition database you are in when you run the command. -
INFORMATION_lists how much data every sharded table is using on each partition in the cluster.SCHEMA. TABLE_ STATISTICS This is a great way to check where data skew is coming from.
Last modified: