MySQL Performance Tuning - you must understand the importance of 15 variables
Preface:
MYSQL WEB should be the most popular back-end database. Although recent NOSQL increasingly being mentioned, but I believe most architects will choose to do MYSQL data storage. The author summarizes sort MySQL performance tuning 15 important variables, they need to supplement inadequate also hope big brother said.
1.DEFAULT_STORAGE_ENGINE
If you are already using MySQL 5.6 or 5.7, and your table is InnoDB, it means that you have set up. If not, make sure your table is converted to InnoDB and set default_storage_engine to InnoDB.
why? In short, because InnoDB is a MySQL (including Percona Server and MariaDB) best storage engine - it supports transactions, high concurrency, has a very good performance (when configured correctly). Here are detailed version describes why
2.INNODB_BUFFER_POOL_SIZE
The InnoDB is the most important variable. In fact, if your main storage engine InnoDB, then for you, this variable for MySQL is the most important.
Substantially, innodb_buffer_pool_size specifies how much memory should be allocated to a MySQL InnoDB buffer pool, InnoDB buffer pool for storing cache data, secondary index, dirty data (but no changes have been flushed to disk data) and a variety of internal structures such as adaptive hash index.
According to experience, in a separate MySQL server should be assigned to the entire MySQL 80% of total memory machines. If your MySQL running on a shared server, or if you want to know the InnoDB buffer pool size is set correctly, a detailed look at this.
3.INNODB_LOG_FILE_SIZE
InnoDB redo log file settings in the MySQL community is also called the transaction log. Until the transaction log default value of MySQL 5.6.8 innodb_log_file_size = 5M is the single largest killer of InnoDB performance. Starting MySQL 5.6.8, the default value upgrade to 48M, but a little busy for many systems, far lower.
According to experience, you should set the size of the log can be written in the amount of energy stored for 1-2 hours when your server is busy. If you do not want too much trouble, then set the size of 1-2G performance will let you have a good performance. This variable is also important, more detail see here.
Before entering the next variable, let's take a quick mention about innodb_log_buffer_size. "Quick reference" because it is often difficult to understand and often excessive attention. In fact in most cases you only need a small buffer - is committed and written to the hard disk before you save enough small transaction changes in the transaction.
Of course, if you have a large number of large transactions change, then change the value greater than the default innodb log buffer size will have on your performance has improved to some extent, but you are using autocommit, or your transaction changes less than a few k, that was to keep the default value of it.
4.INNODB_FLUSH_LOG_AT_TRX_COMMIT
By default, innodb_flush_log_at_trx_commit set to 1 InnoDB refresh immediately after each transaction commit synchronize data to the hard disk. If you use autocommit, then your every INSERT, UPDATE, or DELETE statement is a single transaction commits.
Synchronization is an expensive operation (especially when you do not have write-back caching), because it involves actual physical hard disk synchronous write. So, if possible, it is not recommended to use the default value.
Two alternative values are 0 and 2:
-
0 means flushed to the hard disk, but not synchronized (no actual IO operations when the transaction is committed)
- 2 said they did not and do not refresh sync (no actual IO operations)
So if you set it to 0 or 2, the synchronous operation is performed once per second. So obvious disadvantage is that you may be missing the second of submitted data. Specifically, your transaction has been submitted, but the server immediately off, and then you submit the equivalent of did not happen.
Display, for financial institutions, such as banks, which can not be tolerated. But for most sites, you can set innodb_flush_log_at_trx_commit = 0 | 2, even if the server crashes ultimately no big problem. After all, only there are many sites still use MyISAM, lose data when the collapse of the 30s (not to mention that maddeningly slow repair process) a few years ago.
So, what is the actual difference between 0 and 2 that? Significant performance difference is negligible, because the operating system cache refresh operation is very fast. So obviously should be set to 0, in case of the collapse of MySQL (not the entire machine), you will not lose any data because the data is already in the OS cache will eventually be synchronized to the hard disk.
5.SYNC_BINLOG
There are already a large number of documents written sync_binlog, and the relationship between it and the innodb_flush_log_at_trx_commit of, let's brief account of:
a) If your server is not set from the server, and you do not back up, then set sync_binlog = 0 will have good performance.
b) If you have a backup from the server and do, but if you do not mind missing some of the events in the binary log when the primary server crashes, for better performance or to sync_binlog = 0.
c) If you have a backup from the server and you are very concerned about the consistency from the server, and can be restored in time to a point in time (by using the latest consistent backups and binary log to restore the database to a specific point in time capability), then you should set innodb_flush_log_at_trx_commit = 1, and the need to seriously consider using sync_binlog = 1.
The problem is the relatively high cost of sync_binlog = 1 - now also sync once per transaction to the hard disk. You might be thinking why do not the two combined into one synchronized, correct idea - a new version of MySQL (5.6 and 5.7, MariaDB and Percona Server) has been able to merge commit, then in this case sync_binlog = 1 operation is not so expensive, but still have a great impact on performance in the old mysql versions.
6.INNODB_FLUSH_METHOD
The innodb_flush_method set O_DIRECT to avoid double buffering. The only case you should not use when you O_DIRECT operating system does not support. But if you're running Linux, use O_DIRECT to activate direct IO.
Without direct IO, double buffering will happen, because all database changes are written to the first OS to synchronize the cache before the hard disk - so InnoDB buffer pool cache and OS will hold a same data at the same time. Especially if your pool is limited to 50% of the total memory, that means that write-intensive environment, you may be wasting up to 50% of the memory. If no limit is 50%, probably due to the high pressure OS server cache will be used to swap.
Simply put, set innodb_flush_method = O_DIRECT.
7.INNODB_BUFFER_POOL_INSTANCES
MySQL 5.5 buffer is introduced as an example of a means to reduce the internal lock contention MySQL to improve throughput.
In this version 5.5 to enhance the throughput of little help, and then in the MySQL 5.6 version of the upgrade is very big, so you might MySQL5.5 conservatively set innodb_buffer_pool_instances = 4, in MySQL 5.6 and 5.7 you can set examples 8-16 pool.
After you set up observation will find little to improve performance, but in most high load conditions, it should have good performance.
By the way, do not expect this setting you can reduce the response time of a single query. This is the only difference I can see on the server highly concurrent load. For example, multiple threads at the same time do a lot of things.
8.INNODB_THREAD_CONCURRENCY
You may often hear should set innodb_thread_concurrency = 0 then do not leave it. But this is only correct when the low-load server. Then, if your server's CPU or IO use are exposed to saturation, especially occasional peak, this time in the system want to overload the normal process the query, it is strongly recommended attention innodb_thread_concurrency.
InnoDB there is a way to control the number of threads executing in parallel - we called concurrency control mechanism. Most are controlled by the innodb_thread_concurrency value. If set to 0, concurrency control is closed, so InnoDB immediately processed all incoming requests (as much).
When you have 32CPU core and only four requests are no problem. But just imagine you at the core and 32 4CPU request - if you make 32 requests processed simultaneously, you the trouble. Because these 32 requests only 4 CPU core, apparently slower than usual at least eight times (actually more than 8 times), and then these requests each with its own external and internal locks, which is very likely accumulate request .
Here's how to change this variable, the mysql command-line prompt execution:
SET global innodb_thread_concurrency = X;
for most workloads and servers, set 8 is a good start, then you can reach this limit according to server resource utilization gradually increases insufficient use. You can see the current situation through query processing show engine innodb status \ G, look similar to the following line:
22 queries inside InnoDB, 104 queries in queue
9.SKIP_NAME_RESOLVE
This one had to be mentioned, because there are still a lot of people did not add this one. You should add skip_name_resolve to avoid DNS resolution when connected.
In most cases this will not change what you feel, because the DNS server to resolve very quickly in most cases. But when a DNS server fails, it will appear on your server appears "unauthenticated connections", which is why all of the requests are suddenly beginning to slow down.
So do not wait for this to happen before the change. Now add this variable and avoid host-based authorization name.
10.INNODB_IO_CAPACITY, INNODB_IO_CAPACITY_MAX
-
innodb_io_capacity: When used when flushing dirty data, control MySQL amount of write IO executed per second.
- innodb_io_capacity_max: Under pressure to control the amount of write IO MySQL executed per second when flushing dirty data
First, it has nothing to do with reading - SELECT query execution. For read operations, MySQL will do the maximum possible processing and returns the result. As for the write operation, MySQL will refresh cycle in the background, in each cycle will check how much data needs to be refreshed, and will not do with more than a refresh operation innodb_io_capacity specified number. This includes changing the buffer merge (they flushed to disk before changing the buffer is critical auxiliary storage of dirty pages).
Second, I need to explain what is meant, MySQL called "emergency", "under pressure", when the MySQL refresh in the background, some of the data it needs to be refreshed in order to allow the new write operations to come. Then, MySQL will use innodb_io_capacity_max.
So, you should set innodb_io_capacity and innodb_io_capacity_max Why?
The best method is to measure your storage settings random write throughput, and then to innodb_io_capacity_max set your device to achieve maximum IOPS. innodb_io_capacity is set to 50-75% of it, especially if your system is mainly a write operation.
Usually you can predict your system IOPS is. RAID10 a hard disk, for example, consisting of 8 15k do random writes per second, about 1000, so you can set innodb_io_capacity = 600 and innodb_io_capacity_max = 1000. Many low-cost enterprise SSD can do 4,000-10,000 IOPS and so on.
This value is set Debu perfect little problem. However, note that the default limit your write throughput 200 and 400, so you may occasionally capture the refresh process. If this happens, it may have reached your hard disk is write IO throughput, or the value is set too low limits the throughput.
11.INNODB_STATS_ON_METADATA
If you are running MySQL 5.6 or 5.7, you do not need to change the default value innodb_stats_on_metadata, as it has been set correctly.
But MySQL 5.5 or 5.1, it is strongly recommended to close this variable - if it is open, as the command show table status query INFORMATION_SCHEMA immediately rather than waiting a few seconds and then executed, it will use the extra IO operations.
From the 5.1.32 release, this is a dynamic variable, which means you do not need to restart the MySQL server to close it.
12.INNODB_BUFFER_POOL_DUMP_AT_SHUTDOWN & INNODB_BUFFER_POOL_LOAD_AT_STARTUP
Innodb_buffer_pool_dump_at_shutdown and has nothing to do with performance innodb_buffer_pool_load_at_startup these two variables, but if you occasionally restart the mysql server (such as a valid configuration), then it is relevant. When the two are activated, the contents of the buffer pool MySQL (more specifically, cache page) stored in a file at the stop MySQL. When you next start MySQL, it starts a background thread to load the contents of the buffer pool to increase the speed to a 3-5 warm-up times.
Two things:
First, it does not actually copy the contents to a file buffer pool when closed, simply copy the page table space ID and ID - sufficient information to locate the pages on disk. Then it will be able to read those pages load very fast with a lot of order, rather than requiring thousands of small random read.
Second, when you start it is to load content in the background, because MySQL does not need to wait until the buffer pool content loading is complete before you start accepting requests (it does not seem to have any effect).
Starting from MySQL 5.7.7, only 25% of the default buffer pool pages being stored in the mysql close the file, but you can control this value - innodb_buffer_pool_dump_pct, recommendations 75-100.
This feature is only supported from MySQL 5.6.
13.INNODB_ADAPTIVE_HASH_INDEX_PARTS
If you are running a large number of server MySQL SELECT query (and has been optimized as much as possible), then the adaptive hash index at your next bottleneck. Adaptive hash index is a dynamic index InnoDB internal maintenance, you can improve the performance of the most common query patterns. This feature can restart the server shut down, but open by default in all versions of mysql.
This technology is very complex, in most cases it will most types of queries until the effect of accelerating. However, when you have too many queries to the database, at a certain point it will spend too much time waiting for AHI locks and latches.
If you are MySQL 5.7, we do not have this problem - innodb_adaptive_hash_index_parts default setting is 8, so the adaptive hash index is cut into eight partitions, because global mutex does not exist.
But in the version prior to 5.7 mysql, no number of partitions AHI control. In other words, there is a global mutex to protect the AHI, may result in your select query often hit the wall.
So if you are running a 5.1 or 5.6, and a large number of select query, the simplest solution is to switch to the same version of Percona Server to activate the AHI partition.
14.QUERYCACHETYPE
If people think that a good query cache results, should certainly use it. Well, sometimes it is useful. But this is only useful when you are in a low load, most especially at low load is to read, write or not a small amount.
If that is the case, a query_cache_type = ON and query_cache_size = 256M enough. But remember not to set a higher value of the 256M, otherwise it will fail because the query cache, causing the server to cause serious pause.
If your MySQL server high-load operation, it is recommended to set query_cache_size = 0 and query_cache_type = OFF, and restart the server to take effect. As Mysql query cache mutex will stop at all the queries.
15.TABLE_OPEN_CACHE_INSTANCES
MySQL 5.6.6 from the beginning, the table cache can be divided into multiple partitions.
Table cache used to store the current list of open tables, each table when opening or closing the mutex is locked - even if it is an implicit temporary table. Use multiple partitions absolute reduction potential contention.
Starting from MySQL 5.7.8, table_open_cache_instances = 16 is the default configuration.
Like this article authors point to remember followers Oh, updated daily java related articles