How to test tidb with sysbench

It is recommended to use Sysbench 1.0 Or later updates , Can be found in  Sysbench Release 1.0.14 page download .

Test plan

TiDB To configure

Raise the log level , You can reduce the number of print logs , Yes TiDB Has a positive impact on performance . Specific in TiUP Add to profile ：

server_configs: tidb: log.level: "error"

TiKV To configure

elevated TiKV The log level of is also conducive to improving performance .

TiKV There are multiple clusters Column Family, Include Default CF、Write CF and LockCF, It is mainly used to store different types of data . about Sysbench test , Need to pay attention to Default CF and Write CF, Importing data Column Family stay TiDB The proportion in the cluster is fixed . The ratio is ：

Default CF : Write CF = 4 : 1

stay TiKV It needs to be configured according to the memory size of the machine RocksDB Of block cache, To make the most of memory . With 40 GB Deploy a virtual machine in memory TiKV For example , Its block cache The recommended configuration is as follows ：

server_configs: tikv: log-level: "error" rocksdb.defaultcf.block-cache-size: "24GB" rocksdb.writecf.block-cache-size: "6GB"

You can also use sharing block cache How to set ：

server_configs: tikv: storage.block-cache.capacity: "30GB"

More detailed TiKV For parameter tuning, please refer to  TiKV Memory parameter performance tuning .

Testing process

Be careful

The tests in this document do not use such as HAproxy And other load balancing tools . stay TiDB On a single node Sysbench test , And add the results . Load balancing tools and different version parameters also affect performance .

Sysbench To configure

The following is a Sysbench Sample configuration file ：

mysql-host={TIDB_HOST} mysql-port=4000 mysql-user=root mysql-password=password mysql-db=sbtest time=600 threads={8, 16, 32, 64, 128, 256} report-interval=10 db-driver=mysql

Its parameters can be adjusted according to actual needs , among  TIDB_HOST  by TiDB server Of IP Address （ Multiple addresses cannot be written in the configuration file ）,threads  Is the number of concurrent connections in the test , Can be found in “8, 16, 32, 64, 128, 256” Medium adjustment , When importing data , It is recommended to set threads = 8 perhaps 16. After the adjustment , Save the file with the name  config  The file of .

The configuration file Reference examples are as follows ：

mysql-host=172.16.30.33 mysql-port=4000 mysql-user=root mysql-password=password mysql-db=sbtest time=600 threads=16 report-interval=10 db-driver=mysql

Data import

Be careful

If TiDB The optimistic transaction model is enabled （ The default is pessimistic lock mode ）, When concurrency conflicts are found , The transaction will be rolled back . take  tidb_disable_txn_auto_retry  Set to  off  The automatic retry mechanism after transaction conflict will be enabled , Try to avoid transaction conflict and error reporting Sysbench The problem of program exit .

Before data import , Need to be right TiDB Make simple settings . stay MySQL Execute the following commands in the client ：

set global tidb_disable_txn_auto_retry = off;

Then exit the client .

Restart MySQL The client performs the following SQL sentence , Create database  sbtest：

create database sbtest;

adjustment Sysbench The order in which the script creates the index .Sysbench according to “ Build table -> insert data -> Create index ” Import data in order . about TiDB for , This method will take more import time . You can speed up the data import by adjusting the order .

Suppose you use Sysbench Version is  1.0.14, You can modify it in the following two ways ：

1. Download directly as TiDB Modified  oltp_common.lua  file , Cover  /usr/share/sysbench/oltp_common.lua  file .
2. take  /usr/share/sysbench/oltp_common.lua  Of the  235  Go to the first place  240  Move line to 198 After that .

Be careful

This operation is optional , Only the data import time is saved .

The command line type the following command , Start importing data ,config The file is the file configured in the previous step ：

sysbench --config-file=config oltp_point_select --tables=32 --table-size=10000000 prepare

Data preheating and statistical information collection

Data preheating can load the data in the disk into the memory block cache in , The preheated data greatly improves the overall performance of the system , It is recommended to warm up the data every time the cluster is restarted .

Sysbench 1.0.14 There is no function of data preheating , Therefore, it is necessary to preheat the data manually . If you use updated Sysbench edition , You can use the built-in preheating function .

With Sysbench A table in sbtest7 For example , The implementation is as follows SQL Statement to warm up data ：

SELECT COUNT(pad) FROM sbtest7 USE INDEX (k_7);

Statistical information collection helps the optimizer choose a more accurate execution plan , Can pass  analyze  Command to collect tables sbtest Statistical information , Every table needs statistics .

ANALYZE TABLE sbtest7;

Point select The test command

sysbench --config-file=config oltp_point_select --tables=32 --table-size=10000000 run

Update index The test command

sysbench --config-file=config oltp_update_index --tables=32 --table-size=10000000 run

Read-only The test command

sysbench --config-file=config oltp_read_only --tables=32 --table-size=10000000 run

common problem

Under high concurrent pressure ,TiDB、TiKV The configuration is reasonable , Why is the overall performance still low ？

This situation may be related to the use of proxy of . You can try directly to single TiDB compression , Use the sum result proxy To compare the situation of .

With HAproxy For example .nbproc  Parameter can increase its maximum number of started processes , Newer versions of HAproxy And support  nbthread  and  cpu-map  etc. . These can reduce the adverse impact on its performance .

Under high concurrent pressure , Why? TiKV Of CPU Utilization is still very low ？

TiKV Although the whole CPU Low , But some modules CPU It may have reached a high utilization rate .

TiKV Other modules of , Such as storage readpool、coprocessor and gRPC The maximum concurrency limit of can pass TiKV The configuration file of .

adopt Grafana Of TiKV Thread CPU The monitoring panel can observe its actual utilization . If there is a multi-threaded module bottleneck , It can be adjusted by increasing the concurrency of this module .

Under high concurrent pressure ,TiKV Also not reached CPU Use bottleneck , Why? TiDB Of CPU Utilization is still very low ？

On some high-end devices , It uses NUMA Architecturally CPU, Span CPU Accessing remote memory will greatly reduce performance .TiDB By default, all servers will be used CPU,goroutine Inevitably, there will be cross CPU Memory access .

therefore , It is suggested that NUMA On the architecture server , Deploy  n  individual TiDB（n = NUMA CPU The number of ）, At the same time TiDB Of  max-procs  The value of the variable is set to and NUMA CPU Same number of cores for .