Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: TIKV内存使用和什么有关？
[TiDB Usage Environment] Production Environment
[TiDB Version]
[Encountered Problem: Phenomenon and Impact]
I would like to ask what factors affect the memory usage of TiKV nodes?
Is it related to the number of regions? But I see that in my current TiKV nodes, all of them are using 1.5T of data, yet some use over 60G of memory while others use less than 35G. This indicates that it is not related to the number of regions or the data volume. So, what is it related to?
Why is there no leader on 58?
TiKV memory is generally resident memory. If not configured, it uses about 80% of the physical machine.
Are the server configurations uniform?
Node 58 might be unstable, but it’s unclear where the instability lies. Previously, the leader on node 58 frequently went offline, and over time, possibly due to TiDB’s mechanism, it stopped assigning the leader to it altogether. So now it’s like this~
Try using pd-ctl to check if there is a leader eviction schedule.
How should I look at this specifically? Could you please guide me, teacher?
Is there a problem with my command? Or is it a version issue? Why can’t I see it? I’m using v4.0.9.
There is an evict-leader-scheduler above, and it is estimated that 58 was evicted by this.
Memory is closely related to RocksDB.
The underlying TiKV consists of two RocksDB instances.
In RocksDB, there are blockcache and memtable.
For memory tuning, refer to:
How can I view detailed information about evict-leader-scheduler? I’m not familiar with the command.
I looked at the documentation, and it says that TiKV’s memory usage is mainly related to the block-cache, which is associated with hot data and not directly related to the size of the data. The write-buffer, from what I see, has a very small actual memory configuration. There’s also the page cache used for queries.
scheduler config evict-leader-scheduler
Block-cache is a cache that can be adjusted in size. The larger it is, the more hot data it can cache, which is beneficial for reducing query latency.
This command doesn’t work, strange~
The image link you provided appears to be broken or inaccessible. Please provide the text you need translated.
Are you saying like this? It still doesn’t work.
I found it from here, I remember seeing it before as well.
Mine is version 5.4.0, and I can see it too.
If your version is before 4.0, you won’t be able to view it.
Strange, I saw the explanation of this command in the official documentation for version 4.0, and it has this usage. Why can’t I use it?
I don’t have the 4.X version here either.
You can use scheduler -h to check the help; all the commands and prompts are available.
|
username: jaybing926
|
username: 
|
username: 
|
username: 