Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: tidb-v6.5.0-tidb_mem_quota_query参数疑问
[TiDB Usage Environment] Production Environment / Testing / PoC
Testing
[TiDB Version]
6.5.0
[Reproduction Path] What operations were performed when the issue occurred
The cluster was upgraded from 5.4.3 to 6.5.0
[Encountered Issue: Issue Phenomenon and Impact]
The business occasionally reports an Out Of Memory Quota error.
The meaning of the parameter tidb_mem_quota_query has changed significantly compared to before.
I would like to ask if a session is a long connection, for example, running continuously for 10 days, will the memory keep accumulating until tidb_mem_oom_action is triggered?
[Resource Configuration]
[Attachments: Screenshots/Logs/Monitoring]
May I ask if a session is a long connection, for example, running continuously for 10 days, will the memory keep accumulating until tidb_mem_oom_action is triggered?
If during these 10 days, the long connection is in a sleep state for some periods, will the memory be automatically released?
This parameter refers to the memory used during the execution of SQL by a single session. Once the SQL execution is completed in a session, the occupied memory can be released. If it is just sleeping, what memory is it occupying? Even the session itself only occupies a very small portion.
The meaning of 6.5.0 has changed; it is a session, not a single SQL.
A session can only execute one SQL at a time. To execute the next one, you have to wait for the previous one to finish.
Do you consider 10 SQL statements executed serially in the same thread as one session or multiple sessions?
Yes, so if this session continues to execute multiple SQL statements intermittently, will it keep accumulating memory? This is my point of concern. Based on our current test observations, it does accumulate, but it is unclear when the memory will be released.
After executing a query, the occupied memory should be released. Even if the cache is not immediately cleared, it can be reused. If the situation you measured is indeed accumulating without releasing, then there must be a bug.
It’s hard to say. There were no errors reported before the upgrade, but after the upgrade, quite a few OOMs were triggered.
You can check it on the dashboard.
Changes in the execution plan can lead to different memory usage. You can try using ANALYZE TABLE.
With version 6.5, global memory control has greatly improved the OOM situation. For the specific reasons why the system encounters OOM, you can start a new thread and post the relevant logs so that the experts can take a look and determine the cause.
Thank you, I have found the cause. It is due to the tidb_server_memory_limit parameter, which was introduced in version 6.4.0 and defaults to 2GB. With many connections and a larger SQL query, it reports “Out Of Memory Quota.”
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
|
username: magongyong
|
username: 
|
username: 
|
username: 
|
username: