You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 28, 2021. It is now read-only.
sql: implement memory management system for caches
This PR implements a memory management system, intended to have
control over the allocated memory for caches so that they can be
freed at any moment and we can avoid out of memory errors.
The main changes are the following:
- MemoryManager in the sql package, which is just the component that
tracks all caches. Memory of all freeable caches can be freed
using the Free method of this component. The only way to instantiate
new caches is using the NewXXXCache methods.
- Rows, history and LRU cache implementations, accessed using the
NewXXXCache methods of MemoryManager.
- Reporters, which is a component that reports the maximum amount
of memory the program is allowed to use and the currently used memory.
This interface is meant for making testing easier. There is a default
ProcessMemory reporter that returns the memory used by the process and
the maximum memory defined in the `MAX_MEMORY` environment variable.
- MemoryManager is passed down to every component through *sql.Context,
which meant a little more boilerplate on the server SessionBuilder.
- GroupBy, Sort, Distinct and Join now use the provided APIs of memory
and cache management for their in-memory computations.
Caveats:
- We need to think of a good default so that memory usage won't grow
forever and crash eventually, which is the behaviour when MAX_MEMORY is 0.
Signed-off-by: Miguel Molina <[email protected]>
Copy file name to clipboardexpand all lines: README.md
+4-5
Original file line number
Diff line number
Diff line change
@@ -141,8 +141,7 @@ SET <variable name> = <value>
141
141
|:-----|:-----|:------------|
142
142
|`INMEMORY_JOINS`|environment|If set it will perform all joins in memory. Default is off.|
143
143
|`inmemory_joins`|session|If set it will perform all joins in memory. Default is off. This has precedence over `INMEMORY_JOINS`.|
144
-
|`MAX_MEMORY_JOIN`|environment|The maximum number of memory, in megabytes, that can be consumed by go-mysql-server before switching to multipass mode in joins. Default is the 20% of all available physical memory.|
145
-
|`max_memory_joins`|session|The maximum number of memory, in megabytes, that can be consumed by go-mysql-server before switching to multipass mode in joins. Default is the 20% of all available physical memory. This has precedence over `MAX_MEMORY_JOIN`.|
144
+
|`MAX_MEMORY`|environment|The maximum number of memory, in megabytes, that can be consumed by go-mysql-server. Any in-memory caches or computations will no longer try to use memory when the limit is reached. Note that this may cause certain queries to fail if there is not enough memory available, such as queries using DISTINCT, ORDER BY or GROUP BY with groupings.|
146
145
|`DEBUG_ANALYZER`|environment|If set, the analyzer will print debug messages. Default is off.|
147
146
|`PILOSA_INDEX_THREADS`|environment|Number of threads used in index creation. Default is the number of cores available in the machine.|
148
147
|`pilosa_index_threads`|environment|Number of threads used in index creation. Default is the number of cores available in the machine. This has precedence over `PILOSA_INDEX_THREADS`.|
0 commit comments