Tài liệu MySQL Administrator''''s Bible- P9 doc

MySQL Server Tuning 10 InnoDB storage engine options InnoDB is a very widely used storage engine in production systems. There are a number of con- figuration options for the InnoDB engine, and Table 10-4 covers these options. TABLE 10-4 InnoDB Configuration Options Option Name Purpose innodb_buffer_pool_size = buffer_size A static variable that specifies the size of the cache for InnoDB data and indexes. innodb_flush_log_at_trx_ commit = number There are three possible options {0|1|2}. This dynamic system variable manages how often the InnoDB log buffer is written (flushed) to the log file. innodb_flush_method = IO_access_method This static variable determines how the InnoDB storage engine interacts with the operating system with respect to I/O operations. innodb_log_buffer_size = buffer_size Buffer used for writes to the InnoDB logs. Unless you use very large BLOBs this static variable should not be over 8 MB, and can be set to 2 Mb. innodb_log_file_size = log_file_size A static variable that determines the size of each Innodb log file (ib_logfile). innodb_log_files_in_group = number_log_files A static variable that determines the total number of Innodb log files. innodb_max_dirty_pages_pct= N This dynamic variable specifies the maximum percentage of pages in the in Innodb buffer pool that can be dirty — that is, changed in the buffer pool in memory without being saved to disk. Defaults to 90 (%). innodb_thread_concurrency = N This dynamic variable determines the maximum number of system threads inside InnoDB. A good number to start is twice the number of CPUs. All of the InnoDB server variables are GLOBAL in nature. The single most important InnoDB configuration variable is the innodb_buffer_pool_size. Assuming the server is only running mysqld and most of your tables are InnoDB tables, the majority of your memory should be dedicated to the InnoDB buffer pool. It is safe to begin at 367 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Part III Core MySQL Administration 50–70 percent of your system memory allocated the InnoDB buffer, and adjust up or down as you need to. If you have a large amount of RAM (16 Gb or more) on a dedicated MySQL server, then the buffer pool can be an even larger percentage of overall memory. When configuring a server, choose a starting value for the InnoDB buffer pool, set the other configuration values, then determine how much memory is still available. On Unix, the vmstat, top,andfree commands show memory information. In Windows, the Task Manager can show you memory usage. To determine if the InnoDB buffer pool is appropriately sized, run: SHOW GLOBAL STATUS LIKE ’innodb_buffer_pool_pages%’; ■ Innodb_buffer_pool_pages_data is the total number of used data pages (clean and dirty). ■ Innodb_buffer_pool_pages_dirty is the number of dirty data pages. The number of clean data pages can be calculated from these first two status variables. ■ Innodb_buffer_pool_pages_flushed is the number of data pages that have been flushed to disk. ■ Innodb_buffer_pool_pages_free is the number of unused data pages. ■ Innodb_buffer_pool_pages_misc is the number of data pages used for InnoDB over- head. ■ Innodb_buffer_pool_pages_total is the total number of pages. Calculate the ratio of unused data pages to the total number of pages: Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total If the ratio is high (close to 1), then the InnoDB buffer pool is probably set too high. A less likely cause is that the innodb_max_dirty_pages_pct system variable is set too low, and dirty pages are being flushed very often, freeing up pages long before they are needed. Conversely, if the ratio is low, the size of the InnoDB buffer pool may need to be set higher. Using the information you have about the free memory on your system, increase the InnoDB buffer pool size, restart mysqld, and continue to monitor the status variables after the newly sized InnoDB buffer pool has been used for a while. Continue the adjust-monitor-adjust cycle, and once your system is at the right level, continue to monitor levels, making sure to check performance once every month or two. Make sure to always leave a buffer of a half-gigabyte or so of memory because mysqld performs very poorly when it is forced to use swap space. Keep in mind that under high load, mysqld will use more memory. 368 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. MySQL Server Tuning 10 The innodb_flush_log_at_trx_commit system variable is used to manage how often the InnoDB log buffer sends writes to the InnoDB log. When this parameter is set to 0, the log buffer is written every second and the logs file flushes to disk. When this value is 1 (the default), every commit will make the log buffer write to the log file. The log file is flushed to disk on each commit as well. This is required for ACID compliance. For more information on ACID compliance and transactions, see Chapter 9. When set to 2, every commit makes the log buffer write to the file, just as when the value is 1. However, the log file flushes to disk every second, just as when the value is 0. Setting this vari- able to 0 or 2 changes the database to no longer be ACID–compliant — it does not meet the requirements for durability. Because of the log file flushing being different from the transaction commit, it is possible that a crash could lose a second of transactions (actually, slightly more than a second, because of process-scheduling issues). When the variable is set to 0, a crash of mysqld or the operating system may cause this lack of durability; when this variable is set to 2, only an operating system crash may cause this lack of durability. Note that many operating systems and some disk hardware tell mysqld that the flush has taken place even though a flush has not happened. In these cases, the durability requirement of ACID compliance not met, regardless of the value of innodb_flush_log_at_trx_commit. A crash (for example, due to a power outage) can even corrupt the InnoDB database. Using a battery-backed disk cache in the disk or disk controller will protect against this scenario, and regular file flushes will be faster, too. The innodb_flush_method variable has three possible values: ■ fsync is the default option and uses the fsync() system call to flush both data and log files. ■ O_DIRECT will bypass the operating system cache for both reads and writes of data and log files. ■ O_SYNC uses the fsync() system call for data files but for log files uses O_SYNC. There are many times when using O_DIRECT will significantly improve performance of mysqld. This is because it removes the buffering of the operating system. Do not use O_DIRECT with- out using a RAID controller that has a battery backed write cache. This can overcome problems because of operating system crashes that otherwise do not complete a write to the hard drives. In addition, you should enable what is called writeback on the cache. When the server sends data to be flushed to the RAID controller, the controller immediately tells the server the flush is complete. The server considers it committed and is free to do other task. The RAID controller then flushes the writes stored in the cache periodically. This batches the writes and makes them more efficient. If you are considering using O_DIRECT, carefully test your setup to make sure you are getting the best performance possible. With some configurations using O_DIRECT can actually impede performance so be careful! 369 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Part III Core MySQL Administration Using O_SYNC is usually a slower alternative than using O_DIRECT, but there are some edge cases where it can prove to be faster. As with O_DIRECT, it is important that you test your setup to see if server performance benefits. On very write-intensive systems a performance boost can be found by creating larger InnoDB log files. The reason why is that the larger the size of the log file, the less checkpoint flush activity, which saves disk I/O. However, the larger your log files are the longer the recovery time will be after a crash. The default size for the InnoDB log files is only 5 MB. Even with 64-MB log files you should have recovery times under a minute. The maximum size is 4 GB for all the InnoDB log files. It is very common to set these to between 128 and 256 MB. See tip for how to change the InnoDB log file size. To change the size of your InnoDB log files: ■ Shut down mysqld. ■ Edit the configuration file, setting a new log file size with the innodb_log_file_size option. ■ Move the existing InnoDB log files to a backup location. ■ Start mysqld. ■ Verify that the new log files are the correct size. ■ The previous InnoDB log files can be deleted. The innodb_max_dirty_pages_pct server variable sets the percentage of pages allowed to be changed ( "marked dirty") before a flush to disk is performed. A page in this context is a fixed amount of system memory. With the InnoDB storage engine a page is 16k in size. Allowing a higher percentage of dirty pages before a disk flush could increase performance. The default is 90 percent. Falcon storage engine options The new Falcon storage engine is designed to utilize large amount of memory to increase perfor- mance. Table 10-5 shows the configuration option that will affect performance on your server. TABLE 10-5 Falcon Configuration Options Option Name Purpose falcon_record_memory_max=buffer_size Sets the maximum size of the data cache 370 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. MySQL Server Tuning 10 The falcon_record_memory_max variable is used to determine the size of the buffer used for the Falcon storage engine. If your server is only using Falcon tables then this should be set to use most of the available memory (much like the previous suggestions for the InnoDB buffer pool). Maria storage engine options The Maria storage engine is designed to be a replacement for MyISAM. It has many similar characteristics to MyISAM but includes transactional support and automatic crash recovery. Table 10-6 shows the configuration option that affects performance for the Maria storage engine. TABLE 10-6 Maria Configuration Options Option Name Purpose maria_pagecache_ buffer_size Configures the cache size for data and index pages. This is similar to the InnoDB buffer pool. If you are using a large number of Maria tables you should increase the buffer size. By default it is only 8 MB. Query cache options Effectively utilizing the query cache can significantly improve the performance of mysqld.The query cache is covered in great detail in Chapter 12, including explanations of the options and how to tune the query cache. Dynamic variables So far, we have been discussing how to change your system variables by modifying the con- figuration file. While changing the option file is necessary for a change that will persist across mysqld restarts, there are times when you do not want to restart mysqld to change a system variable — perhaps you are testing and only want to set a variable temporarily. However, it is possible to dynamically change many of the server variables. For example, the variables relating to query cache setup and management can be changed without a server restart. However, the innodb_buffer_pool_size variable cannot be changed dynamically and requires a server restart with the option specified. Session variables, by their nature, are always dynamic, as they are set per session. 371 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Part III Core MySQL Administration If you make a change to a dynamic variable while it is running, do not forget to change your configuration file or the next time you restart the server you may have an unexplained performance drop, or other behavior revert to an unpleasant state. The MySQL manual maintains a list of mysqld system variables, their scope (GLOBAL or SESSION), and if they are dynamic or static. The web page for version 6.0 is: http://dev.mysql.com/doc/refman/6.0/en/server-system-variables.html Similarly, the MySQL manual page for status variables, which can be used for monitoring perfor- mance, is located at: http://dev.mysql.com/doc/refman/6.0/en/server-status-variables.html To access information for other release series (5.1, for example), just replace the 6.0 in the above address with the release series. If a system variable can be changed dynamically it is modified using the SET GLOBAL, SET SESSION, SELECT @@global or SELECT @@session command. Recall our previous example of the SHOW GLOBAL STATUS command and the temporary tables for the server with a 54 percent conversion ratio of in-memory temporary tables to on-disk temporary tables. To see the current maximum temporary table size, use the following SHOW VARIABLES command: mysql> SHOW GLOBAL VARIABLES LIKE ’%tmp%’; + + + | Variable_name | Value | + + + | max_tmp_tables | 32 | | slave_load_tmpdir | /tmp/ | | tmp_table_size | 33554432 | | tmpdir | /tmp | + + + 4 rows in set (0.00 sec) This shows a current setting of 32 MB. To increase this to 48 MB, we issue either of the follow- ing commands: mysql> SET GLOBAL max_tmp_tables=48; Query OK, 0 rows affected (0.00 sec) mysql> SET @@global.max_tmp_tables=48; Query OK, 0 rows affected (0.00 sec) After some time, recalculate the conversion ratio to see if the change is helping. Of course, once a final decision is made on the size allowed for temporary tables, edit the configuration file and set the new value to persist when mysqld restarts. 372 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. MySQL Server Tuning 10 SUMMARY This chapter covers a great deal of information. While there is not enough space to cover every part of server tuning you should understand the basics of tuning the hardware, operating sys- tem, and mysqld. Topics covered included: ■ Choosing the best hardware ■ CPU choice ■ Memory ■ Disk storage ■ Operating system tuning ■ Choosing an operating system ■ File system tuning ■ Tuning mysqld ■ The configuration file ■ Storage engine configuration ■ Dynamic variables 373 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Storage Engines IN THIS CHAPTER Understanding storage engines Using different storage engines Working with storage engines T he storage engines of MySQL are one of the most unique features of the server. Approximately twenty major storage engines are currently available, and though they allow for the ultimate flexibility when working with your data, this diversity can be intimidating to the beginning or even intermediate level database administrator. Most database administrators regularly work with two storage engines, MyISAM and InnoDB, and may use others in a handful of projects. Understanding Storage Engines A storage engine is a subsystem that manages tables. Most database man- agement systems have one subsystem to manage tables; MySQL Server can use different subsystems. Because a storage engine is applied at the table level, it is sometimes called table type. CREATE TABLE and ALTER TABLE statements can use the ENGINE option to set (or change) the storage engine that is associated with the table. The MySQL pluggable storage engine is an architectural design that sepa- rates the code that manages the tables from the database server core code. This core code manages the components such as the query cache, the opti- mizer, and the connection handler. The storage engine code handles the actual I/O of the table. This separation of code allows for multiple storage engines to be used by the same core server. Once you have the ability to have multiple storage engines at the same time, the database administrator can choose a storage engine based on its ability to meet the requirements of an application. This is vastly different from most other database manage- ment systems, where there is no choice. 375 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Part III Core MySQL Administration Though each storage engine handles its own I/O, mysqld requires a table format file for each file. These files have an .frm extension. Having different storage engines allows MySQL to have many different features, and many storage engines are produced by third-party companies. InnoDB, the most frequently used transactional storage engine, is actually produced by a different company. This means that people can develop storage engines that meet their own needs, without having to wait for a feature to be released. Storage engines as plugins Even though the name implies that storage engines are easily added and removed from MySQL, it was only starting in MySQL Server version 5.1 that storage engines have been able to be plugins. The pluggable part of pluggable storage engines reflects the separation of code, not the nature of how to add a storage engine (compiled-in vs. plugin). Innobase Oy, the company that created the InnoDB storage engine ( www.innodb.com), has a plugin version of its storage engine. This plugin includes several features not available in the compiled-in InnoDB that ships with MySQL, including: ■ Ability to ADD or DROP indexes (except primary keys) without requiring a table copy ■ On-the-fly compression and decompression of table data ■ New tables in the information_schema database Another storage engine that uses the same plugin methodology is the PBXT engine developed by PrimeBase Technologies ( www.primebase.org). The benefit to this architecture is immediately obvious; the release cycle of the storage engine plugin can be completely independent from the server. Neither Innobase nor Primebase Technologies have to wait for Sun Microsystems to release a new version of MySQL Server for a bug fix or a feature addition to either stor- age engine. A new version of the storage engine plugin can be released at any time and an administrator can upgrade just that one component. One example of how this is beneficial is that beginning with version 5.1, MySQL Server allows a storage engine to be able to create or drop indexes without copying the contents of the entire table. However, a storage engine has to write the code to implement this functionality. The InnoDB storage engine integrated into MySQL Server version 5.1 does not take advantage of this capability. With the InnoDB plugin, however, users can add and drop non-primary indexes much more efficiently than with prior releases. Using the plugin, a database administrator can upgrade the plugin instead of the entire MySQL Server, and have this functionality. Storage engine comparison You can easily use multiple storage engines in a single application. This ability to use multiple storage engines can lead to optimal results for the application. This is because different parts of the application will have different requirements. One storage engine cannot be a perfect fit 376 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... the WEBSITE The default storage engine for mysqld is MyISAM To change this, set the default_storage_engine option in the configuration file For example: default_storage_engine=InnoDB MyISAM storage engine MyISAM is the default storage engine in mysqld, and is the storage engine used by the system tables It has been a reliable storage engine for MySQL Server since MySQL Server version 3.2, replacing the... one of the tables needed repair you could just run: $ myisamchk –r /var/lib /mysql/ mysql/table_name.MYI When running myisamchk you must manually block all access to the tables being checked Otherwise, corruption could occur The easiest and best way to accomplish this is simply to shut down mysqld If you need to check tables while mysqld is running, consider using the CHECK TABLE command as described in... done while the server is online, release any read locks on the table and issue a FLUSH TABLES command to force mysqld to recognize and begin using the new table If mysqld was shut down, restart it Additional information is available on the various options in the MySQL Manual at http:// dev .mysql. com/refman/6.0/en/myisampack.html myisam_ftdump The myisam_ftdump program will provide information about... watermark Storage Engines To change the block size of existing tables, you should use mysqldump to create a backup of the table data, stop mysqld, remove the maria_log_control file, and change the maria_block_size parameter before starting up mysqld again The configuration settings are stored in the maria_log_control file when mysqld is started with the Maria engine enabled The default block size is 8192 bytes... not run myisam_ftdump in the directory where the table files are, you will receive an error such as: got error 2 Additional information about myisam_ftdump is available from the MySQL Reference Manual at http://dev .mysql. com /doc/ refman/6.0/en/myisam-ftdump.html Merge storage engine The Merge storage engine is actually a sort of wrapper table that wraps around MyISAM tables with the same schemas All... tables, this should be a significant percentage of the total memory available to mysqld Be very careful with this setting because if it is configured to use too much memory it will cause swapping by the operating system, which is very bad for mysqld performance In the worst-case scenario, using too much memory will cause mysqld to crash See Chapter 10 for more details on tuning this parameter SHOW ENGINE... started, process no 30716, OS thread id 1195391328 MySQL thread id 336895572, query id 1972768750 172.17.0.67 db1user -TRANSACTION 1 2117126605, not started, process no 30716, OS thread id 1175120224 MySQL thread id 336895571, query id 1972768749 172.17.0.66 db1user -TRANSACTION 1 2117126604, not started, process no 30716, OS thread id 1179134304 MySQL thread id 336895567, query id 1972768746 172.17.1.71... thread id 1168898400 MySQL thread id 336895564, query id 1972768743 172.17.0.66 db1user Sending data SELECT * FROM blocklist WHERE userid = ’572692’ -TRANSACTION 1 2117126598, not started, process no 30716, OS thread id 1370806624 MySQL thread id 336895563, query id 1972768711 172.17.0.67 db1user -TRANSACTION 1 2117126371, not started, process no 30716, OS thread id 1375623520 MySQL thread id 336895338,... SHOW ENGINE InnoDB STATUS to the standard output of mysqld Standard output would typically be your error log This done by creating a table called innodb_monitor: mysql> CREATE TABLE innodb_monitor (a INT) ENGINE=INNODB; Query OK, 0 rows affected (0.03 sec) Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 389 11 Part III Core MySQL Administration Now until you drop the table... tablespace files: ■ Perform a logical export (using a logical export tool such as mysqldump) of all the InnoDB tables ■ Shut down mysqld ■ Change the configuration options as desired to remove or reorganize a tablespace ■ Move the existing ibdata files, ib_logfile log files, and frm table definition files to a backup location ■ Restart mysqld The new ibdata file(s) will take some time to initialize ■ Import the . web page for version 6.0 is: http://dev .mysql. com /doc/ refman/6.0/en/server-system-variables.html Similarly, the MySQL manual page for status variables,. storage engine in mysqld, and is the storage engine used by the system tables. It has been a reliable storage engine for MySQL Server since MySQL Server version