Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: TIDB5.1版本tikv进程占用的内存居高不下。
|
username: TiDBer_RQobNXGv
During this period, I manually restarted once, and the memory usage went down, but after a month, it went up again. The block cache is set to 6GB.
Check the TopSQL on the Dashboard to see if there are any large SQL queries?
You have mixed nodes here! The configuration is 1 PD, 1 TiDB, and 2 TiKV.
Yes, even with hybrid deployment, it’s strange that the TIKV process is consuming so much memory.
The first SQL, executing it twice per second? The execution frequency is a bit high.
I just noticed it’s a mixed deployment, and it’s a single server with 2 TiKV instances mixed. This can easily cause resource contention.
It looks like an SQL issue, or you can check the TopSQL in the dashboard. Additionally, mixed deployment can cause resource contention.
Your configuration resources are insufficient, consider scaling up. Don’t mix deployments; one server should have only one node.
Has storage.block-cache taken effect? Versions prior to v6.6.0 only work when shared block cache is enabled.
[storage.block-cache]
Whether to create a shared block cache for all CFs of RocksDB.
RocksDB uses block cache to cache uncompressed data blocks. A larger block cache can speed up read operations.
It is recommended to enable the shared block cache parameter. This way, you only need to set the total cache size, making the configuration process more convenient.
In most cases, the LRU algorithm can automatically balance cache usage among different CFs.
The remaining configurations in the storage.block-cache session only take effect when shared block cache is enabled.
Starting from v6.6.0, this option is always enabled and cannot be disabled.
The size of the shared block cache. Normally, it should be set to 30%-50% of the total system memory.
If this parameter is not set, it is determined by the sum of the following fields or their default values.
Note this sentence: ## To deploy multiple TiKV nodes on a single physical machine, you need to explicitly configure this parameter.
TiDB uses the LSM-Tree memory algorithm, which is inherently memory-intensive. If you want to reduce memory usage, you can adjust its parameters to flush memory to disk more quickly for persistence.
My fifth node is a standalone TiKV, and its memory usage is also too high.
Can you post the slow SQL here? Maybe the read/write load is too high???
The image is not visible. Please provide the text you need translated.
The image is not visible. Please provide the text you need translated.
Take a look at this parameter, which adjusts memory writing to disk: max-write-buffer-number.
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: