Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: tidb执行sql完成后内存能手动释放吗?我这边发现内存不会立即释放,后续执行sql可能会导致内存占用越来越高,最后导致被系统杀掉。
The image is not visible. Please provide the text you need translated.
Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: tidb执行sql完成后内存能手动释放吗?我这边发现内存不会立即释放,后续执行sql可能会导致内存占用越来越高,最后导致被系统杀掉。
The image is not visible. Please provide the text you need translated.
Restarting can release it… otherwise, just wait for Go memory GC.
There is a memory scheduling mechanism to release memory, but it does not release the memory immediately after execution.
Memory will be automatically released, no need for manual release. What is your version? If the version is below 6.5, it is recommended to upgrade. The release operation is much more proactive in versions after 6.5.
The TiDB server is developed in Go language, which has a GC (Garbage Collection) mechanism for periodic memory release. For specific details, refer to the GC section of the TiDB server configuration parameters.
Significant release. Otherwise, your graph will keep rising. I encountered this before with other data warehouses.
I think it’s better to focus on troubleshooting large SQL queries.
This part still needs to consider large SQL, it will release, but sometimes very slowly.
You can try lowering the following parameter to make the Golang GC more frequent:
No manual release is needed; it will be automatically reclaimed.
It will not be released immediately; there will be a gogc action. Generally, it will not keep increasing to the point of causing a restart, which would imply a memory leak or a bug.
Which version of TiDB are you using? The higher versions of TiDB are quite good, with significantly fewer OOM issues.
The version in the screenshot is 5.1.1, and the process was killed and restarted by the system due to high memory usage. I upgraded to version 7.1 in the past two days and configured memory limits, but I found that memory reclamation is too slow. As a result, many queries are killed by TiDB without returning results. Will expanding TiDB nodes significantly improve this situation?