Recommended Values for Various Metrics of Thread CPU in TiDB Monitoring TIKV-Details

This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: TIDB监控中TIKV-Details—>Thread CPU各项指标的建议值

| username: residentevil

【TiDB Usage Environment】Production Environment
【TiDB Version】V6.5.8
【Encountered Issue: Phenomenon and Impact】The recommended values for various indicators in TIKV-Details—>Thread CPU in TiDB monitoring. I have looked at some optimization solutions from the official documentation. Some components can be optimized through configuration, but for some monitoring items, the effect is still not obvious after modifying the configuration. Especially for the UnifyReadPool monitoring indicator, if there are many rows read by SQL, this indicator directly affects SQL latency. Has anyone encountered this issue?

Online configuration [Server 96C, deployed 4 TIKV instances]: = true
readpool.unified.max-thread-count = 30
readpool.unified.min-thread-count = 5

| username: WalterWj | Original post link

Not a single core is being used, it’s not high at all.

| username: residentevil | Original post link

Currently, there are no read requests. When the read requests reach over 10,000, the utilization will be very high.

| username: zhanggame1 | Original post link

Have you also set readpool.coprocessor.use-unified-pool: true?

| username: redgame | Original post link

Run it first by default, then take a look.

| username: tidb菜鸟一只 | Original post link


Is it enabled? Automatically adjust the size of the thread pool (UnifyReadPool) that handles read requests uniformly.

| username: residentevil | Original post link

I checked, and this configuration is turned off. Is the parameter reliable?

| username: residentevil | Original post link

Set to TRUE

| username: tidb菜鸟一只 | Original post link

Your server has 96 cores and 4 TiKV instances deployed on it. Have you done NUMA resource isolation? Also, the setting readpool.unified.max-thread-count = 30 is a bit high; it is recommended to set it to around 19, which is 96/4*0.8. Additionally, the parameter is more reasonable to enable when your CPU peak can reach around 1500% (with readpool.unified.max-thread-count set to 19).

| username: TiDBer_aaO4sU46 | Original post link

96/4*0.8=19, learned something new.

| username: residentevil | Original post link

If the parameter is set, then specifying readpool.unified.max-thread-count = 30 is meaningless, right?

| username: 小龙虾爱大龙虾 | Original post link

Optimize SQL, why scan so much data? Also, with your 96-core machine and 4 TiKVs, your unified read pool is probably using less than 30, which isn’t enough.

| username: tidb菜鸟一只 | Original post link

max-thread-count is also the adjustment threshold for this parameter.

| username: residentevil | Original post link

SQL-level optimization has been done, but after some SQL queries use indexes, there are still many row retrievals.

| username: residentevil | Original post link

I will adjust and run the stress test to see.

| username: dba远航 | Original post link

The pressure is not too high.

| username: 烂番薯0 | Original post link

I haven’t changed anything.

| username: FutureDB | Original post link

Is it because there are many Index Full Scans?