Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: 调整完tidb-server的并行会话数后,tikv的内存超出限制一倍,oom了
tidb 5.0.1
In order to increase TiDB’s parallel processing capability, the token-limit parameter of TiDB was increased from 300 to 600. The memory limit for TiKV was set to 75G, but then TiKV experienced OOM (Out of Memory). The memory usage of a single TiKV node reached 180G and then it OOMed. After adjusting the parallel session count of the TiDB server, the TiDB server was not affected, but the memory usage of TiKV doubled and then OOMed. All 8 TiKV nodes experienced OOM one after another. This parameter did not take effect: storage.block-cache.capacity: 75G
The storage.block-cache.capacity is just a limit for the block cache of the underlying RocksDB, not the overall memory of TiKV. There are many other modules within TiKV that also consume memory. It seems like the increase in concurrency leads to more requests hitting TiKV, resulting in higher memory usage. Check the TiKV detail page to see if there are any abnormal increases before and after changing the concurrency parameters.
I saw in the documentation that there is no limit on the maximum number of connections.
The number of sessions and the number of connections are not the same thing?
There is no limit on the number of sessions. This refers to how many can work together at the same time. Any sessions beyond this number will have to wait for the previous ones to release the token.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.