MySQL Performance Tuning London Meetup June 2017
4 likes1,183 views
The document discusses various techniques for tuning MySQL performance. It begins with an introduction and agenda, then covers top performance issues such as bad SQL queries, long running transactions, and incorrect configurations. The rest of the document provides tips for monitoring different aspects of the system and tuning various configuration options, software, and application design factors to optimize MySQL performance.
![MEMORY ALLOCATOR
• jemalloc is a good malloc replacement
[mysqld_safe]
malloc-lib=/usr/lib64/libjemalloc.so.1
Default with MariaDB
• tcmalloc shipped on Linux with MySQL
[mysqld_safe]
malloc-lib=tcmalloc](https://image.slidesharecdn.com/mysqlperformancetuninglondonmeetupjune2017-170622204627/85/MySQL-Performance-Tuning-London-Meetup-June-2017-19-320.jpg)
![CPU USAGE TUNING
• taskset command on Linux for core assignment
• taskset -c 1-4 `pidof mysqld`
• taskset -c 1,2,3,4 `pidof mysqld`
• niceness
[mysqld_safe]
nice=-20
also in /etc/security/limits.conf
• CPU governor
• set to performance](https://image.slidesharecdn.com/mysqlperformancetuninglondonmeetupjune2017-170622204627/85/MySQL-Performance-Tuning-London-Meetup-June-2017-20-320.jpg)
MySQL Performance Tuning London Meetup June 2017
- 1. MYSQL PERFORMANCE TUNING Arnaud Adant June 21 2017 The London MySQL
- 2. WHO I AM • aadant@jumptrading.com • 3.5 years @ Oracle MySQL as support engineer – Filed hundreds of bugs and feature requests • InnoDB • Optimizer • High availability • Performance • Joined Jump Trading in 2015
- 3. AGENDA • Introduction • Mostly performance tuning tips • this presentation is an update from the 50 tips presentation done while at Oracle for MySQL 5.6 • Questions
- 4. TOP PERFORMANCE ISSUES • Bad SQL queries : 90 % of the time • Long running idle transaction • high history_list_length • MDL • Replication lag • no primary key and row based replication • Wrong / bad configuration • smaller buffer pool, query cache, small redo logs • OS, hardware
- 5. PERFORMANCE CHECK LIST • #1 Monitor the queries … • tune the apps • #2 Monitor replication • tune replication • #3 Monitor the status variables • tune the config • #4 Monitor the OS • tune the OS • #5 in doubt, benchmark
- 6. THE APP (DEFINITION) • Everything that is not shipped with the database • schema • queries • user connections • the app data in data files • …
- 7. TUNING PROCESS replication status variables mysqld Monitor / measure backup Tune the app Config /design config variables benchmark OS OS config variables OS the app app design data files
- 8. CHANGE PROCESS • One change at a time, test on dev = prod, then deploy Development Production deploy Change Test Monitor OK Monitor
- 9. TUNING PROCESS 1. Config • OS • Config variables • App design • Benchmark 2. Monitor • App / status variables / replication / mysqld / os 3. Tune using the change process • App • Config variables • Table spaces • OS
- 10. CONFIG / OS 1/2 • RAM • CPU • Storage • OS • OS limits • Battery backed disk cache • Memory allocator • CPU affinity
- 11. CONFIG / OS 2/2 • I/O scheduler • File system • Mount options • Disk configuration • NUMA
- 12. RAM • The active data should fit in the buffer pool • MySQL connections and caches take memory • ECC RAM recommended • Enable huge pages for large buffer pools : large-pages • Extra RAM for • FS cache • Monitoring • RAM disk (tmpfs) • RAM is split over NUMA nodes
- 13. CPU • Fast CPU for single threaded performance • Recent servers have 32 to 80 cores. • Enable hyper-threading • MySQL 5.7 scales to 64 cores • Minimize the number of sockets !
- 15. STORAGE • Good for IO bound loads • HDD for sequential reads and writes • Bus-attached SSD for random reads and writes • NVMe : Non-Volatile Memory Express • Big sata or other disk for log files • Several disks ! If striping, mind the stripe size, align • Life time for low end SSD is a concern
- 16. OPERATING SYSTEM • Linux ! • pick a modern distribution • also works well on Windows, FreeBSD, MacOS, Solaris
- 17. OS LIMITS (LINUX) • Max open files per process • ulimit –n • limits the number of file handles (connections, open tables, …) • Max threads per user • ulimit –u • limits the number of threads (connections, event scheduler, shutdown)
- 18. BATTERY BACKED DISK CACHE • Usually faster fsyncs • InnoDB redo logs • binary logs • data files • Crash safety • Durability (ACID) • Applies to SSD
- 19. MEMORY ALLOCATOR • jemalloc is a good malloc replacement [mysqld_safe] malloc-lib=/usr/lib64/libjemalloc.so.1 Default with MariaDB • tcmalloc shipped on Linux with MySQL [mysqld_safe] malloc-lib=tcmalloc
- 20. CPU USAGE TUNING • taskset command on Linux for core assignment • taskset -c 1-4 `pidof mysqld` • taskset -c 1,2,3,4 `pidof mysqld` • niceness [mysqld_safe] nice=-20 also in /etc/security/limits.conf • CPU governor • set to performance
- 21. FILE SYSTEM • ext4 best choice for speed and ease of use • fsyncs a bit slower than ext3 • more reliable • xfs is excellent (for experts only) • With innodb_flush_method = O_DIRECT • less stable recently • ext3 is also a good choice
- 22. MOUNT OPTIONS • ext4 (rw,noatime,nodiratime,nobarrier,data=ordered)* • xfs (rw, noatime,nodiratime,nobarrier,logbufs=8,logbsize=32k) • SSD specific • innodb_use_trim • innodb_page_size = 4K • Innodb_flush_neighbors = 0 * use no barrier if you have a battery backed disk cache
- 23. I/O SCHEDULER • deadline is generally the best I/O scheduler • echo deadline > /sys/block/{DEVICE-NAME}/queue/scheduler • the best value is HW and WL specific • noop on high end controller (SSD, good RAID card …) • deadline otherwise
- 24. DISK CONFIGURATION • everything on one disk is killing performance • several disks (RAID) • or distribute the data files on different disks • data files (ibd files) • main InnoDB table space ibdata • redo logs • undo logs (if separate) • binary logs
- 25. NUMA • NUMA architecture is the norm nowadays for mysql server • Problem : RAM is allocated to CPU sockets • The Buffer pool should be distributed in each RAM • Percona, MariaDB and MySQL >= 5.6 support NUMA • The usual trick is using mysql_safe • flush the FS cache --flush-caches • use NUMA interleave --numa-interleave
- 26. NUMA • From 10.1, 5.7, -- innodb-numa-interleave • Allocates the buffer pool at startup • “Replaces” innodb_buffer_pool_populate • Default off • “For the innodb_numa_interleave option to be available, MySQL must be compiled on a NUMA-enabled Linux system MariaDB : only custom builds MDEV-12924
- 27. CONFIG / VARIABLES 1/2 • Buffer pool size • Query cache off • Use a thread pool • Cache the tables • Cache threads • Per thread memory usage • Default storage engine • Buffer pool contention
- 28. CONFIG / VARIABLES 2/2 • Large redo logs • IO capacity • InnoDB flushing • Thread concurrency • InnoDB table spaces • Transaction isolation • Replication : sync_binlog • Replication : parallel threads • Connector configuration
- 29. INNODB BUFFER POOL SIZE • innodb_buffer_pool_size • Not too large for the data • Do not swap ! • Beware of memory crash if swapping is disabled • Active data <= innodb_buffer_pool_size <= 0.8 * RAM
- 30. DISABLE THE QUERY CACHE • Single threaded cache, removed in 8.0 • Only if threads_running <= 4 • Becomes fragmented • Cache should be in the App ! • Off by default from 5.6 • query_cache_type = 0 • query_cache_size =0 • Problem if qcache_free_blocks > 50k
- 31. ENABLE THE THREAD POOL • https://www.percona.com/blog/2014/01/23/percona-server- improve-scalability-percona-thread-pool/ • Stabilize TPS for high concurrency • Useful if threads_running > hardware threads • Decrease context switches • Several connections for one execution thread • Acts as a Speed Limiter • MySQL commercial, Percona, MariaDB
- 32. TABLE CACHING • table_open_cache • not too small, not too big • opened_tables / sec • table_definition_cache • do not forget to increase • opened_table_definitions / sec • table_cache_instances = 8 or 16 (MySQL and Percona only) • innodb_open_files • mdl_hash_instances = 256 (in 5.7, no more an issue)
- 33. THREAD CACHING • Thread creation is expensive, so caching is important • thread_cache_size • decreases threads_created rate • capped by max user processes (see OS limits) • 5.7.2 refactors this code • Default value is calculated in 5.7 • http://dev.mysql.com/doc/refman/5.7/en/server-system- variables.html#sysvar_thread_cache_size
- 34. INNODB STORAGE ENGINE • Should be the default storage engine • Do not use MyISAM unless you know what you are doing • The most advanced storage engine is InnoDB • Scalable • Temporary tables use InnoDB in 5.7 • the memory engine is still used when using less then tmp_table_size
- 35. BUFFER POOL CONTENTION • innodb_buffer_pool_instances >= 8 • Reduce rows_examined / sec (see Bug #68079) • 8 is the default value in 5.6 ! • innodb_spin_wait_delay = 96 on high concurrency • Use read only transactions when possible
- 36. LARGE REDO LOGS • Redo logs defer the expensive changes to the data files • Recovery time is no more an issue • innodb_log_file_size = 2047M before 5.6 • innodb_log_file_size >= 2047M from 5.6 • Bigger is better for write QPS stability • You want to avoid “furious flushing” • innodb_log_files_in_group = 2 is usually fine
- 37. IO CAPACITY • IO capacity should mirror device IO capacity in IOPS • innodb_io_capacity should be larger for SSD • Impacts flushing • In 5.6, innodb_lru_scan_depth is per buffer pool instance • so innodb_lru_scan_depth = innodb_io_capacity / innodb_buffer_pool_instances • Default innodb_io_capacity_max = min(2000, 2 * innodb_io_capacity) • From 5.7, innodb_page_cleaners, default = 4
- 38. PER THREAD MEMORY USAGE • Each thread allocates memory • estimates = max_used_connections * ( read_buffer_size + read_rnd_buffer_size + join_buffer_size + sort_buffer_size + binlog_cache_size + thread_stack + 2 * net_buffer_length … + n * tmp_table_size where n >= 0 ) For a more accurate measure, check the performance_schema memory metrics or MariaDB select * from information_schema.processlist.
- 39. THREAD CONCURRENCY • No thread pool : • innodb_thread_concurrency = 16 - 32 in 5.5 • innodb_thread_concurrency = 36 in 5.6 • align to HW threads if less than 32 cores • Thread pool : • innodb_thread_concurrency = 0 (unlimited) is fine • innodb_max_concurrency_tickets : higher for OLAP, lower for OLTP
- 40. INNODB FLUSHING • Redo logs : • innodb_flush_log_at_trx_commit = 1 // best durability • innodb_flush_log_at_trx_commit = 2 // better performance • innodb_flush_log_at_trx_commit = 0 // best performance • Data files only : • innodb_flush_method = O_DIRECT // Linux, skips the FS cache • Increase innodb_adaptive_flushing_lwm (fast disk)
- 41. INNODB_FILE_PER_TABLE • Default value : 1 table = 1 table space = 1 ibd file • Not so good for small tables. • Good for large tables. • Default value from 5.6, before all tables in system table space. • From 5.7, a user defined table space can now host several tables. • http://dev.mysql.com/doc/refman/5.7/en/create-tablespace.html
- 42. TRANSACTION ISOLATION • Default = REPEATABLE-READS • Oracle database, Sybase ASE default is READ-COMMITTED • Less locking, no gap locks, less overhead • transaction-isolation = REPEATABLE-READ • If you enable READ-COMMITTED, make sure binlog_format=ROW.
- 43. REPLICATION DURABILITY • Replication is crash safe from 5.6 • Replication state was stored in files • Now stored in InnoDB tables in the mysql schema • However the binary logs are stored on disk : • sync_binlog = 1 • no reason not to use from 5.6
- 44. MULTI-THREADED REPLICATION • MariaDB slave_parallel_threads • MySQL / Percona : slave_parallel_workers • >1 when lag is a concern • For a recent comparison, see https://www.percona.com/live/data- performance-conference-2016/sites/default/files/slides/ 2016-04-21_plmce_mysql_parallel_replication-inventory_use- case_and_limitations.pdf
- 45. CONNECTOR TUNING • Connectors can also be tuned. • JDBC property for maximum performance : • userConfigs=maxPerformance • Use if the server configuration is stable • Removes frequent • SHOW COLLATION • SHOW GLOBAL VARIABLES • Fast validation query : /* ping */
- 46. APPLICATION DESIGN 1/2 • Schema design • Indexes at the right place • Remove redundant indexes • Reduce rows examined • Reduce sent rows • Minimize locking • Minimize temporary tables (on disk) • Minimize sorting on disk
- 47. APPLICATION DESIGN 2/2 • Avoid long running transactions • Close prepare statements • Close idle connection • Do not use the information_schema in your app • Views may not not good for performance – temporary tables (on disk) • Replace truncate with drop table / create table • Tune the replication thread • Cache data in the app • Scale out, shard
- 48. SCHEMA DESIGN • create a PK for each table ! • integer primary keys • avoid varchar, composite for PK • latin1 vs. utf8 vs. utf8mb4 • the smallest varchar for a column • smallest data type for a column • keep the number of partitions low (< 100, optimal performance <10) in 5.6. No more an issue in 5.7. • use compression for blob / text data types
- 49. INDEXES • Fast path to data • B-TREE, R-TREE (spatial), full text • for sorting / grouping • without temporary table • covering indexes • contain all the selected data • save access to full record • reduce random reads
- 50. REDUNDANT INDEXES • Not good for write performance • duplicated data • resources to update • confuse the optimizer • Use SYS schema views • schema_unused_indexes
- 51. REDUCE ROWS_EXAMINED • Rows read from the storage engines • Rows_examined • slow query log • P_S statement digests • SYS schema • Handler% • show session status where variable_name like ‘Handler%’ or variable_name like ‘%tmp%’; • optimize if rows_examined > 10 * rows_sent • usually due to missing indexes
- 52. REDUCE ROWS_SENT • Found in the slow query log, the SYS schema • Number of rows that are returned by queries to the clients • rows_sent <= rows_examined • Network / CPU expensive • Client compression can help. • Usually bad design. • Use caching or LIMIT for UI • No human can parse 10k rows
- 53. REDUCE LOCKING • Locking has a performance impact because locks kept are in memory • Can be seen in show engine innodb status • UPDATE, SELECT FOR UPDATE, DELETE, INSERT SELECT • Use a PK ref, UK ref to lock • Avoid large index range and table scans • Reduce rows_examined for locking SQL • Commit when possible
- 54. TEMPORARY TABLES (ON DISK) • Large temporary tables on disk • handler_write (handler_tmp_write, handler_tmp_update in MariaDB) • created_tmp_disk_tables • monitor tmpdir usage • Frequent temporary tables on disk • High created_tmp_disk_tables / uptime • show global status like '%tmp%'; • Available in the SYS schema, select * from sys.statement_analysis
- 55. MIND THE SORT (ON DISK) • Key status variable is : • sort_merge_passes : it is a session variable • if it occurs often, you can try to up sort_buffer_size • find the query and fix it with an the index if possible • http://dev.mysql.com/doc/refman/5.7/en/order-by- optimization.html
- 56. LONG RUNNING (IDLE) TRANSACTIONS • Usually the oldest transactions in show engine innodb status : • High history_list_length (a status variable in MariaDB) • Prevent the purge • Decrease performance • Can also prevent schema changes (due to MDL locks) • Can block backups (FTWRL see MDEV-12620)
- 57. CLOSE PREPARE STATEMENTS • com_stmt_prepare – com_stmt_close ~= 0
- 58. CLOSE IDLE CONNECTIONS • Idle connections consume resources • Either refresh or disconnect them
- 59. MISCELLANEOUS • Do not use the information_schema in your App • Replace truncate with drop table / create table due to • Bug #68184 Truncate table causes innodb stalls, fixed in MySQL 8.0 • Views may not be good for performance • temporary tables (on disk) • joining other views • Scale out, shard
- 60. CACHE DATA IN THE APP • Good for CPU / IO • Cache the immutable or the expiring ! • referential data • memcached / redis • Query cache can be disabled • Identify frequent statements • perl mysqldumpslow.pl –s c slow60s.log • pt-statement-digest • Possibly use proxies such as ProxySQL, MaxScale
- 61. MONITOR THE REPLICATION THREADS • Slow query log with • log-slow-slave-statements is now dynamic (Bug #59860) from 5.6.11 • MySQL and Percona only • Performance_schema >= 5.6.14 • binlog_format = ROW • show global status like ‘Handler%’ • SYS (on table scans), detect tables not having PK • In case of issue with a particular table, check the MDL locks. • MariaDB and 5.7 have a way to see them
- 62. MONITOR / MAINTAIN • Monitor the database and OS • Mine the slow query log • Use the performance_schema and SYS schema • Backup the database • Upgrade regularly
- 63. MONITOR THE DATABASE • essential for any professional DBA • part of the tuning and change processes • alerts • graphs • availability and SLAs • the effect of tuning • query analysis
- 64. MINE THE SLOW QUERY LOG • Dynamic collection • The right interval • Top queries • pt-schema-digest • Sort by query time desc • perl mysqldumpslow.pl –s t slow.log • Sort by rows_examined desc • Top queries at the 60s range
- 65. USE THE SYS SCHEMA • the SYS schema: • good entry point • ready to use views • IO / latency / waits / statement digests • ideal for dev and staging • https://github.com/mysql/mysql-sys • sys 5.6 works with MariaDB 10.1 • overhead is acceptable in most cases (5% for P_S)
- 66. BACKUP THE DATABASE • Backup is always required ! • Method depends on your business : logical vs. physical • Verify the backup • Decrease the overhead on prod • LVM has an overhead • mysqldump eats MySQL resources • mysqlbackup / xtrabackup copy the data files and verify it (in parallel)
- 67. OPTIMIZE THE DATABASE • Fragmentation has an impact on performance • internal fragmentation (inside table spaces) • external fragmentation (on the file system) • OPTIMIZE TABLE fixes it (see also Bug #57583) • can be done online • MariaDB has the iterative defragmentation patch from Facebook / Kakao. • https://mariadb.com/kb/en/defragmenting-innodb- tablespaces/
- 68. MONITORING FRAGMENTATION • There is no general formula • except for fixed length records • create table t_defrag like t; insert into t_defrag select * from t limit 20000; • Fragmentation if Avg_row_length(t) > Avg_row_length(t_defrag) • Avg_row_length from show table status
- 69. MONITORING FRAGMENTATION • There is no general formula • except for fixed length records • create table t_defrag like t; insert into t_defrag select * from t limit 20000; • Fragmentation if Avg_row_length(t) > Avg_row_length(t_defrag) • Avg_row_length from show table status
- 70. UPGRADE POLICY • Security vulnerability fixes • Bug fixes • Performance improvements • Ready for the next GA • Never upgrade without testing (see change process) • can be automated • the DBA is also a QA engineer !
- 71. POINTERS • The MySQL manual • bugs.mysql.com • Percona’s blog • https://planet.mysql.com/ • 50 tips to improve MySQL performance (2014) • Dimitrik’s latest slides and blog • Bill Karwin’s Tuning MySQL Its about performance (2015) • Bill Karwin’s SQL anti-patterns • https://www.percona.com/live/17/resources/slides are freely available !!! • FOSDEM videos https://video.fosdem.org/2017/H.1309/ • MariaDB • My blog : http://aadant.com/blog
- 72. QUESTIONS?