Environment introduction
Hardware Configuration
| number of cpu cores | memory size | disk space |
|---|---|---|
| 16 cores | 256G | 3T |
Software Environment
| OS version | mysql version | number of tables | Number of rows in a single table |
|---|---|---|---|
| centos-7.4 | mysql-5.7.22 | 128 tables | 2kw line |
Optimization level and guiding ideology
optimization level
MySQL database optimization can be carried out at many different levels. The common classifications of levels are 1): SQL optimization 2): parameter optimization 3): architecture optimization; this article focuses on the second layer and explains it through a complete optimization case Intrinsic logic of parameter optimization.
guiding ideology
1. Log first -- the key to whether a transaction can be successfully submitted is whether the log related to it is successfully placed on the disk, which has little to do with the data; that is to say, the optimization of writing can be expressed as the writing operation of various resources. tilt.
2. Bottleneck analysis - The current bottleneck can be basically analyzed by the value of each counter of show global status, and the bottleneck can usually be identified by combining some simple system-level monitoring tools such as top iostat.
3. The overall performance is a rebalance between "read" & "write".
optimization process
Performance with minimal installation
Contents of my.cnf
Image address:
http://www.sqlpy.com/mysqlz/tuninglog/result/cm16c256g4096ssd/0/
Monitoring data
Analysis & Optimization Ideas
There are two possible explanations for the monitoring data: 1): Since the buffer_pool_size of the minimized installation is relatively small, the limit of the maximum dirty page of innodb_buffer_pool will be frequently triggered, making innodb enter the mode of explosive disk brushing. In this case io usage will increase significantly. 2): redo log reuse. The final impact may be the superposition of the two, here we start with buffer_pool optimization.
Optimize innodb_buffer_pool_size
Contents of my.cnf
Image address:
http://www.sqlpy.com/mysqlz/tuninglog/result/cm16c256g4096ssd/1/
Monitoring data
The performance comparison before and after adjusting innodb_buffer_pool_size is about 3 times higher. Image address:
http://www.sqlpy.com/mysqlz/tuninglog/compare/cm16c256g4096ssd/0/1/
Analysis & Optimization Ideas
1. The adjustment of innob_buffer_pool_size has achieved certain results. The following adjustment is for the case of redo reuse, that is to say, we need to increase innodb_log_files_in_group and innodb_log_file_size to a suitable value.
2. The adjustment of innob_buffer_pool_size has achieved certain gains and can go further, that is, increase the value of innodb_buffer_pool_instances.
优化innodb_log_files_in_group&innodb_log_file_size
According to the records of the previous test, the LSN increases by 4.5G each time a set of tests is completed, and the duration is about 5 minutes; theoretically, increasing the redo file to 5G can prevent log reuse during the entire test process. The running score will be higher, but this will affect the recovery time of the database downtime. Under the default configuration of MySQL, innodb_log_files_in_group=2, innodb_log_file_size=48M, which means that after running a set of test redo logs, it needs to refresh 48 rounds . First, (1024*4.5/96 ==48) let’s take a look at the situation of adjusting the log refresh to 9 rounds.
Contents of my.cnf
Image address:
http://www.sqlpy.com/mysqlz/tuninglog/result/cm16c256g4096ssd/2/
The performance comparison before and after adjusting innodb_log_files_in_group&innodb_log_file_size is about 2 times higher. Image address:
http://www.sqlpy.com/mysqlz/tuninglog/compare/cm16c256g4096ssd/1/2/
Now look at the performance of log reuse within one round (5G)
Contents of my.cnf
The performance comparison before and after adjusting innodb_log_files_in_group&innodb_log_file_size
is about 2 times higher than the image address:
http://www.sqlpy.com/mysqlz/tuninglog/compare/cm16c256g4096ssd/2/3/
Analysis & Optimization Ideas
1. In the case of increasing redo to 5G, since there is almost no problem of log file reuse during the whole test process, this avoids the large amount of data flushing behavior caused by these, so the performance curve is smoother.
2、通过show global status 发现Table_open_cache_overflows=200W+、Thread_created=2k+
3. %Cpus : 80.5 us, 13.8 sy, 0.0 ni, 5.4 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st The 95% utilization rate of CPU resources has become a big problem. There are not many parameters that can be adjusted under this utilization rate.
3. The monitoring data of the disk shows that the peak value of util has dropped to 14%, and the disk is no longer a problem; therefore, for innodb_buffer_pool_size, innodb_log_files_in_group&innodb_log_file_size, these two optimizations enter into one step to optimize innodb_buffer_pool_instances, innodb_log_buffer_size first; Small" way to adjust the table cache first.
优化table_open_cache&table_open_cache_instances&innodb_sync_spin_loops&thread_cache_size
Since the cpu usage rate has reached 95%, there is a feeling of powerlessness from the heart to see this value, so I plan to adjust some problems that can be clarified in the current status directly; increase table_open_cache&table_open_cache_instances to optimize table cache, increase thread_cache_size usage The cpu does not need to create and destroy threads frequently and increase innodb_sync_spin_loops to avoid context switching as much as possible (since the current monitoring granularity is not particularly fine, it is impossible to give how much of the 13.8% is context switching), that is to say, increase innodb_sync_spin_loops more of professional judgment
Contents of my.cnf
Comparison before and after adjustment
Summarize
Considering that the cpu usage rate has reached 95% and it is unrealistic to increase the physical cpu, it is decided to optimize the MySQL parameters so far; finally, let's take a look at the optimization results.
author:
Author: Jiang Lexing
Time: 2018-05-08
Personal website: www.sqlpy.com