# Identifying and Reducing Memory Usage SingleStore maintains a detailed account of memory usage. An example of a typical question about memory usage is, "*I only have 10GB of tables but I'm using 67GB of RAM? What is that additional memory being used for?*" Run the [SHOW STATUS EXTENDED](https://docs.singlestore.com/db/v9.0/reference/sql-reference/show-commands/show-status-extended.md) command on an individual SingleStore instance to view a detailed break down of memory usage. ## SHOW STATUS EXTENDED The `SHOW STATUS EXTENDED` command displays a list of engine variable values as described in the following sections. ## Summary variables The following summary variables describe overall memory usage. ## Total\_server\_memory `Total_server_memory` tracks the server’s overall memory use. SingleStore does not let this value grow higher than `maximum_memory`. When `Total_server_memory` reaches `maximum_memory`, memory allocations start failing. Queries then fail with the error `1712 - "Not enough memory available to complete the current request. The request was not processed."` In addition, the trace log shows the following: `"Nonfatal buffer manager memory allocation failure. The maximum_memory parameter (XXXXX MB) has been reached."` ## Alloc\_table\_memory `Alloc_table_memory` tracks the memory stored inside of all rowstore tables (memory for rows, indexes, variable-length columns like `VARCHAR` or `JSON` that are stored off row). Once `Alloc_table_memory` reaches `maximum_table_memory`, `INSERT`, `UPDATE`, and `LOAD DATA` operations against the tables receive the following error: `1720 - "Memory usage by SingleStore for tables (XXXXX MB) has reached the value of 'maximum_table_memory' global variable (YYYYY MB). This query cannot be executed."`. ## Buffer\_manager\_memory `Buffer_manager_memory` tracks memory that is allocated by the Buffer Manager for SingleStore’s built-in memory allocators. The Buffer Manager is a component that consumes memory from the Linux OS in 128KB blocks and manages that memory out to memory allocators used by rowstore tables or by query execution. If the application makes heavy use of rowstore tables, it’s normal for `Buffer_manager_memory` to be a large percentage of `Total_server_memory`. ## Buffer\_manager\_cached\_memory `Buffer_manager_cached_memory` tracks cached memory blocks allocated by the Buffer Manager that are currently not in use, but still mapped. Keeping these blocks cached allows later allocations to reuse them without requesting memory from the operating system. Table garbage collection and query execution commonly add freed memory to this cache. Other freed Buffer Manager memory can also be added when it is safe to reuse. `Buffer_manager_unrecycled_memory` reflects the memory that may still be referenced until the check is complete. While `Total_server_memory` is at or below 90% of `maximum_memory` or at least 10 GB of free memory remains, `Buffer_manager_cached_memory` is capped at 25% of `maximum_memory` on each node. When the cache size reaches the capped limit, additional freed memory blocks (or buffers) are returned to the operating system. Buffers that are already cached are still mapped and left in place, therefore crossing the capped limit does not trim the cache. The cache shrinks when a subsequent allocation uses the cached buffer, and it can get unmapped if another allocation may otherwise exceed `maximum_memory`. When `Total_server_memory` is above 90% of `maximum_memory` and less than 10 GB of free memory remains, newly freed buffers are cached only until the cache size reaches approximately 1% of `maximum_memory` (vs. the default 25%). Existing cached buffers are not trimmed when this limit applies. As cached memory stays mapped, `Total_server_memory` includes `Buffer_manager_cached_memory`. After a large rowstore `DELETE`, `Alloc_table_memory` can fall while `Total_server_memory` stays high because the freed memory blocks are still held as unrecycled or cached memory. Refer to [buffer\_manager\_cached\_memory](https://docs.singlestore.com/db/v9.0/user-and-cluster-administration/maintain-your-cluster/managing-memory/buffer-manager-cached-memory.md) for more information. ## Alloc\_query\_execution `Alloc_query_execution` tracks memory allocated by currently executing queries for sorts, hash tables, result tables, etc. If no queries are running, this value should be 0. ## Alloc\_variable `Alloc_variable` tracks memory allocated for variable-length columns inside rowstore tables, or for other variable-length memory allocations inside query execution (i.e. temporary allocations inside of string expressions, etc.). ## Alloc\_vector\_index `Alloc_vector_index` specifies the total size of vector indexes currently residing in memory. The vector index cache loads indexes when they are used and evicts them using an LRU policy when the cache reaches its capacity. ## Row store variables Row store has a set of allocators it uses for various part of an index. These values can be helpful when determining rowstore table size. ## Alloc\_skiplist\_towers `Alloc_skiplist_towers` tracks memory used by the towers for skiplist indexes. Each skiplist index uses on average 40 bytes of memory per row using this allocator. The exact amount of memory per row is probabilistic. It depends on the randomized tower height of the particular row. ## Alloc\_table\_primary `Alloc_table_primary` tracks memory used for on-row data for rowstore tables. SingleStore tables share a single row memory allocation amongst all indexes on a particular table. Variable-length columns are not stored in this allocator (`VARCHAR`, `VARBINARY`, `BLOB`, `TEXT`, `JSON`, etc). Instead, they are stored in `Alloc_variable` that was previously discussed in this topic. ## Alloc\_deleted\_version `Alloc_deleted_version` tracks memory used to mark rows as deleted in rowstore tables. `DELETE` queries in SingleStore don’t free up memory when they commit. They mark rows as deleted and the garbage collector frees this memory up when it is safe to do so (i.e. no query or operation is using the deleted row anymore). If this number is large, it means the garbage collector is behind or some operation is preventing the garbage collector from physically freeing the memory used by deleted rows. Examples of this could be a snapshot or a backup, or a long running query, etc. ## Alloc\_hash\_buckets `Alloc_hash_buckets` tracks memory used for HASH index buckets (by default 4 million buckets per index, which would use 32 MB). ## Other variables A few variables describe memory used by components that are not directly related to running queries or storing data. ## Alloc\_replication `Alloc_replication` tracks the amount of memory used during replication. ## Malloc\_active\_memory `Malloc_active_memory` tracks memory allocated directly from the Linux OS and managed by the C runtime allocators (not SingleStore’s built-in memory allocators that use the Buffer Manager). The memory use here should be approximately 1-2 GBs for most workloads. Column store tables, open connections, and memory for metadata about tables, columns, etc. are the biggest consumers of memory. ## Alloc\_thread\_stacks `Alloc_thread_stacks` tracks memory used by thread stacks. SingleStore caches threads used to run queries. Each thread has a 1 MB stack by default. This can be controlled by the `thread_stack` session variable, but SingleStore does not recommend changing this value. SingleStore kills threads it hasn’t used for 24 hours which frees up stack memory (this can be controlled by the `idle_thread_lifetime_seconds` variable). ## In this section * [Deleting Row Store Table Data When at the Memory Limit](https://docs.singlestore.com/db/v9.0/reference/troubleshooting-reference/identifying-and-reducing-memory-usage/deleting-row-store-table-data-when-at-the-memory-limit.md) * [Reducing Memory Use by Row Store Tables](https://docs.singlestore.com/db/v9.0/reference/troubleshooting-reference/identifying-and-reducing-memory-usage/reducing-memory-use-by-row-store-tables.md) * [Columnstore Table Considerations](https://docs.singlestore.com/db/v9.0/reference/troubleshooting-reference/identifying-and-reducing-memory-usage/columnstore-table-considerations.md) * [Understanding Memory and Disk Usage with Studio](https://docs.singlestore.com/db/v9.0/reference/troubleshooting-reference/identifying-and-reducing-memory-usage/understanding-memory-and-disk-usage-with-studio.md) * [Investigating Memory Usage Discrepancies](https://docs.singlestore.com/db/v9.0/reference/troubleshooting-reference/identifying-and-reducing-memory-usage/investigating-memory-usage-discrepancies.md) *** Modified at: October 19, 2026 Source: [/db/v9.0/reference/troubleshooting-reference/identifying-and-reducing-memory-usage/](https://docs.singlestore.com/db/v9.0/reference/troubleshooting-reference/identifying-and-reducing-memory-usage/) (An index of the documentation is available at /llms.txt)