Hello everyone! I have a question that what memory (RAM) of master aggregator stores and how can i manage them? Typically my Singlestore cluster uses very little memory from the master aggregator. But because of some error it increased very high and I couldn’t release it even after restarting MA. Thank you in advance.
Hi Thao, you say the RAM didn’t release even after the MA was restarted - did you restart Singlestore or the Server itself?
Are you 100% sure it was Singlestore using this extra memory also?
If it was Singlestore, you need to determine what was running that was causing the RAM - you could connect to this using Singlestore Studio and look at active queries , or also run a workload profile from Studio as well. RAM not being released even after restarting the master aggregator in SingleStore could be attributed to several factors .
However, understanding how SingleStore manages memory and other related system behaviours can help in diagnosing and addressing such issues. Here are some potential reasons and areas to investigate based on the general behavior of SingleStore and database systems:
-
Memory Allocation for Buffer Pools and System Caches: SingleStore, like many other database systems, allocates memory for buffer pools, caches, and internal structures to optimize performance. This memory allocation is often substantial and may not be immediately released upon system restarts due to the database’s internal mechanisms and the operating system’s memory management strategies.
-
Persistent Connections and Background Processes: Even after a restart, if there are persistent connections to the database or background processes initiated by SingleStore that remain active, these could hold onto memory resources. This includes processes related to replication, maintenance tasks, or pipelines that may automatically restart upon system boot.
-
Operating System Caching: The operating system itself may cache disk reads and other file operations performed by SingleStore, holding onto memory outside of SingleStore’s direct control. This type of caching is managed by the OS and is intended to speed up disk I/O operations.
-
Configuration Settings: Specific configuration settings in SingleStore may dictate memory usage patterns, including how memory is allocated and released. Settings related to memory limits, buffer pool sizes, and garbage collection thresholds could influence the observed behavior.
A comprehensive review of system logs, SingleStore cluster settings, and operating system performance metrics is recommended.
For further troubleshooting, reviewing the SingleStore documentation, especially sections related to system administration, memory management, and performance tuning, could be beneficial.
Thank you very much for your explanation.
i just discovered that my system is not using any rowstore table. But when I check in information_schema.MV_GLOBAL_STATUS, Alloc_variable and Alloc_table_primary still have large values and cause Alloc_table_memory to reach maximum_table_memory. I think that’s why my system is having error.
I want to know if these two variables serve anything other than the rowstore table and what is the solution to free this memory.
I look forward to hearing from you.
Hi Thao,
Alloc_Variable tracks memory allocated for variable-length columns inside rowstore tables, or for other variable-length memory allocations inside query execution. This means it is used to keep track of memory usage for data that does not have a fixed length, allowing for dynamic allocation based on the size of the data being stored or processed. Variable-length columns could be those defined with data types that allow for varying lengths, such as VARCHAR or TEXT
Alloc_table_primary tracks memory used for on-row data for rowstore tables and the in-memory segments for columnstore tables.
hope this helps
1 Like
hi Mmcelhinney,
Thanks for your respond. I have a better understanding of these two variables.