6 Tips to MySQL Performance Tuning

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
6 Tips to MySQL Performance Tuning
Nitin Mehta
Principal Technical Consultant – MySQL

Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, and timing of any features or
functionality described for Oracle’s products remains at the sole discretion of Oracle.
2

Agenda
3
Oracle Premier Support for MySQL
MySQL Performance Tuning Best Practices
Top 6 Tips
Summary
Q & A
1
2
3
4
5

Oracle Premier Support for MySQL
We’ve Got You Covered

MySQL Enterprise Support
• Provided by the experts, straight from the source
• Backed by the MySQL developers
• World-class support, in 27 languages
• Hot fixes & maintenance releases
• 24x7x365
• Unlimited incidents
• Consultative support
• Global scale and reach
Get immediate help for any MySQL
issue, plus expert advice
5

MySQL Consultative Support
• Troubleshooting using Webex
• Replication review
• Partitioning review
• Schema review
• Query review
• Performance tuning
• ...and more
6
Make the Most of your Deployments

7

• Be wary about “best practices”
– No two systems are the same
– What was true earlier may no longer hold
8

• HW and SW vendors are all lying! Not really.
– Test, Benchmark, Monitor
– One knob at a time
– Use sysbench, mysqlslap, monitoring tools
9

• Think – what you’re doing and why?
10

• Think – what you’re doing and why?
• There are guidelines, not best configurations
11

• Be mindful of your requirements
– Some options give the choice between performance or data safety – what do you
need?
• Often the default value is the best value
• Ensure all tables have a PRIMARY KEY
• InnoDB organizes the data according to the PRIMARY KEY:
– The PRIMARY KEY is included in all secondary indexes in order to be able to locate the
actual row => smaller PRIMARY KEY gives smaller secondary indexes.
– A mostly sequential PRIMARY KEY is in general recommended to avoid inserting rows
between existing rows.
12

Top 6 Tips
Tuning MySQL Performance
13

01. Think
• Thinking is your best defense
• Analyze your performance problem:
– Make sure you understand what the issue is:
• No: performance is too slow
• Yes:
– The query takes 10 seconds, but it is used for interactive use so must complete in 0.1 second or less
– The server must handle 200k queries per second
– Determine the cause
• Don’t jump to conclusions
• Consider the whole stack
• Justify why you think you have found the cause
14

01. Think
• Implement the solution
– List all the solutions you can think of
• Make sure you think outside the box – not just what you assume
– Explain why the solutions will work
– Implement an action plan:
• Test the action plan and update if necessary
• Ensures you implement the solution the same on the test and production systems
• If a regression occurs, you have a record of the steps you made
15

02. Monitoring
• Gives you a base line
• Tells you what has happened – useful to investigate performance issues
• Allows you to proactively handle potential issues
16

02. Monitoring
• Many options available:
– MySQL Enterprise Monitor
– MySQL Workbench
– Slow Query Log
– MySQL Plugin for Oracle Enterprise Monitor
– And many more
• Make sure you configure alerts so you react appropriately to all events
based on the severity level!
17

02. Monitoring
• On Linux perf is a great tool for live monitoring and can record over a time
period
– https://perf.wiki.kernel.org/index.php/Main_Page
– http://www.brendangregg.com/perf.html
• MySQL Enterprise Monitor has some reports to get snapshot data
• Workbench has performance reports based on the sys schema
“Real time” monitoring
18

02. Monitoring
MySQL Workbench Performance Reports
19

02. Monitoring
• The sys schema is a collection of views, functions, and procedures aiming
to make the Information Schema and Performance Schema simpler to use.
• Included by default in MySQL 5.7+
• Also available from https://github.com/mysql/mysql-sys for MySQL 5.6
• Formerly known as ps_helper by Mark Leith
• https://dev.mysql.com/doc/refman/5.7/en/sys-schema.html
What was that sys schema?
20

02. Monitoring
Finding queries to optimize - MySQL Enterprise Monitor Query Analyzer
21

02. Monitoring
Finding queries to optimize – Performance Schema Digest Summary
mysql> SELECT LEFT(DIGEST_TEXT, 64) AS DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT, MAX_TIMER_WAIT
FROM performance_schema.events_statements_summary_by_digest
ORDER BY MAX_TIMER_WAIT DESC
LIMIT 10;
+------------------------------------------------------------------+------------+-----------------+----------------+
| DIGEST_TEXT | COUNT_STAR | SUM_TIMER_WAIT | MAX_TIMER_WAIT |
+------------------------------------------------------------------+------------+-----------------+----------------+
| INSERT INTO `salaries` VALUES (...) /* , ... */ | 342 | 159811231808000 | 4156961573000 |
| INSERT INTO `dept_emp` VALUES (...) /* , ... */ | 42 | 31561264335000 | 2458392698000 |
| INSERT INTO `titles` VALUES (...) /* , ... */ | 63 | 35738435708000 | 1735350241000 |
| INSERT INTO èmployees` VALUES (...) /* , ... */ | 51 | 18004605187000 | 1679817477000 |
| INSERT INTO `sbtest` ( `k` , `c` , `pad` ) VALUES (...) /* , ... | 10 | 5241286782000 | 1247361451000 |
| COMMIT | 342 | 31984662051000 | 992714081000 |
| DROP SCHEMA IF EXISTS èmployees` | 6 | 1252459420000 | 848771265000 |
| CREATE TABLE `sbtest` ( ìd` INTEGER UNSIGNED NOT NULL AUTO_INCR | 1 | 565468324000 | 565468324000 |
| CREATE TABLE `dept_manager` ( `dept_no` CHARACTER (?) NOT NULL , | 3 | 355874700000 | 220491035000 |
| SELECT COUNT (?) AS `cnt` , `round` ( ( `performance_schema` . ` | 6 | 386062170000 | 217206520000 |
+------------------------------------------------------------------+------------+-----------------+----------------+
10 rows in set (0.00 sec)
22

03. Initial Configuration File
1. Start with an empty configuration file
2. Set paths, port, etc.
3. Enable additional monitoring
4. Set capacity settings
5. Don’t do much more!
23

• It can be an advantage to have the paths pointing to separate disk systems
– Reduces contention
– I/O often becomes a bottleneck
– Can place the hot files on faster disks
• For example with innodb_flush_log_at_trx_commit = 1 and high transaction commit rate, it can be
necessary to place the InnoDB redo log on SSDs to support the high rate of flushes.
• Note: File-per-table tablespaces and general tablespaces can belocated
outside datadir when they are created
Paths
24

• If you use InnoDB, enable all the INNODB_METRICS counters:
– innodb_monitor_enable = ‘%’
• The overhead has turned out to be small so worth the extra details
• Ensure the Performance Schema is enabled
– Does have overhead, but provides very useful information for performance tuning
– Consider enabling additional consumers and instruments as required (for example for
transactions in MySQL 5.7)
– The Performance Schema can also be configured dynamically at runtime
Enable additional monitoring
25

• MySQL Reference Manual (about innodb_buffer_pool_size):
“On a dedicated database server, you might set the buffer pool size to 80%
of the machine's physical memory size.”
– What if you have 1TB of memory? Do you still want to reserve 20% for other uses?
• Instead:
– How much memory does the host have?
– Subtract memory required by OS and other processes
– Subtract memory required by MySQL other then the InnoDB buffer pool
– Choose minimum of this and the size of the “working data set”
Capacity settings - innodb_buffer_pool_size
26

• Total redo log size defined by two options:
– innodb_log_file_size
– innodb_log_files_in_group
• Total size = innodb_log_file_size * innodb_log_files_in_group
– Max supported total redo log size:
• MySQL 5.5 and earlier: just below 4G
• MySQL 5.6 and later: just below 512G
• Should be large enough to avoid “excessive” checkpointing
• The larger redo log, the slower shutdowns potentially
Capacity settings – InnoDB redo log
27

• Get current Log sequence number (LSN) and last checkpoint:
– SHOW ENGINE INNODB STATUS:
– INNODB_METRICS:
Capacity settings – InnoDB redo log – Is it large enough?
---
LOG
---
Log sequence number 602763740
Log flushed up to 602763740
Pages flushed up to 584668961
Last checkpoint at 555157885
mysql> SELECT NAME, COUNT
FROM information_schema.INNODB_METRICS
WHERE NAME IN ('log_lsn_current', 'log_lsn_last_checkpoint');
+-------------------------+-----------+
| NAME | COUNT |
+-------------------------+-----------+
| log_lsn_last_checkpoint | 555157885 |
| log_lsn_current | 602763740 |
+-------------------------+-----------+
28

• Calculate the amount of used redo log:
– Used log = log_lsn_current – log_lsn_last_checkpoint
= 602763740 - 555157885
= 47605855 (bytes)
• Compare to total size:
– Used % = (Used log / Total log) * 100
= (47605855 / (innodb_log_file_size * innodb_log_files_in_group)) * 100
= (47605855 / 100663296) * 100
= 47.29 %
29

• If the usage reaches 75% an asynchronous flush is triggered
– I/O can be so intensive that all other work stalls
– Main InnoDB thread may be in the state: flushing buffer pool pages
• Ensure you have enough head room to handle peak loads
– For example aim at using at most 60% or 70% of the redo log
• Important that your monitoring solution monitors the redo log usage
• Improvements to the flushing algorithm and new options to control the I/O
have been added in newer MySQL versions
30

• innodb_undo_tablespaces can only be set before initializing the datadir!
• If set creates undo log tablespaces outside the system tablespace (ibdata1)
• Advantages:
– Keeps the system tablespace smaller
– Can keep the undo log on faster disks
– In MySQL 5.7 the undo log tablespaces can be truncated
• Each undo tablespace file is 10M initially
• Maximum of 95 undo tablespaces in 5.7
InnoDB Undo Log
31

• max_connections – be careful setting this too large as each connection
requires memory
• table_definition_cache – ensure all tables can be in the cache. If you expect
4000 tables, set table_definition_cache > 4000
• table_open_cache – each table can be open more than once
• table_open_cache_instances - Typically a good value is 16
Other capacity options
32

04. Buffers And Caches
• Surely enabling caches is a good thing?
• Surely the larger caches and buffers the better?
Several buffers and caches available
33

• Surely enabling caches is a good thing?
• Surely the larger caches and buffers the better?
• No!
Several buffers and caches available
34

• It is rarely good to enable the Query Cache
– Guarded by a single mutex
• Most workloads is best left with the Query Cache disabled (the default):
– query_cache_type = 0
• If you think your workload benefits from the Query Cache, test it
– The more writes, the less benefit
– The more data fitting into the buffer pool, the less benefit
– The more complex queries and the larger scans, the more benefit
• Often other caching solutions are a better option.
Query Cache
35

• In MySQL 5.5 and earlier: only used for plain index scans, range index
scans, and joins that do not use indexes
– No reason to have it larger than the size of each matching row
• In MySQL 5.6+ also used for Batched Key Access (BKA)
– Queries using BKA can benefit from a larger join buffer
• Is the minimum size allocated!
• Usually a small global (default for new connections) value is best: 32k-256k
• Increase for a session as needed
join_buffer_size
36

• Like for join_buffer_size a small global value is usually best: 32k-256k
• Can monitor using the global status variable Sort_merge_passes:
• Aim at a few Sort_merge_passes per second on a busy server
• Increase for a session as needed
sort_buffer_size
mysql> SHOW GLOBAL STATUS LIKE 'Sort_merge_passes';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Sort_merge_passes | 0 |
+-------------------+-------+
1 row in set (0.00 sec)
37

• Some buffers are allocated in full each time they are used
• One query may use several buffers, so large buffers can cause significant
memory usage
• Memory allocations are relatively expensive
• For example Linux glibc malloc changes memory allocation algorithm when
crossing threshold (typical 256k or 512k).
– Algorithm for larger allocations can be 40 times slower than for smaller allocation
Why is it important with small global values?
38

05. Data Consistency Versus Performance
• Possible values in order of data safety:
– 1: is theoretically the slowest, but with fast SSD it may be around as fast as 2 and 0
– 2: flushed every second (innodb_flush_log_at_timeout in 5.6+)
• Transactions may be lost if the OS crashes
– 0: MySQL never fsyncs
• Transactions may be lost if the OS crashes
• Defaults to 1 – flush the redo log after each commit
– Required for D in ACID
– For this reason it is the recommended value
innodb_flush_log_at_trx_commit
39

• What if innodb_flush_log_at_trx_commit = 1 is too slow and you want the
D in ACID?
– Make sure the redo logs are on separate disks
• Do not be tempted to have the individual redo logs on different disks
– Consider SSD particularly if you have a high commit rate
– Battery-backed disk cache also makes flushes cheaper
innodb_flush_log_at_trx_commit
40

• Specifies how many transactions between each flush of the binary log
– 0: when rotating the binary log or when the OS decides
– 1: at every transaction commit – this is the safest
– N: every N commits
• Default value:
– MySQL 5.6 and earlier: 0
– MySQL 5.7 and later: 1
• MySQL 5.6 and later support group commit for InnoDB giving less overhead
of sync_binlog = 1
sync_binlog
41

• sync_binlog != 1 means that slaves most likely will have to be rebuild if the
master crashes
• But sync_binlog = 0 must be the best performance wise, right?
sync_binlog
42

• sync_binlog != 1 means that slaves most likely will have to be rebuild if the
master crashes
• But sync_binlog = 0 must be the best performance wise, right?
– By default: max_binlog_size = 1G
– 1G is not a lot of memory nowadays
– So the OS may buffer the entire binary log
– When rotating the binary log, up to 1G will be flushed to disk
• Stalls all other commits until the binary log rotation is done
• So in short: sync_binlog = 0 may give the best throughput, but sync_binlog
= 1 may give the most predictable performance
sync_binlog
43

06. Consider the Whole Stack
• The issue may occur at any place in the stack, e.g.:
– Application
– Application host/hardware
– Network between application and host with MySQL
– MySQL host/hardware
– MySQL
• This should also be considered when monitoring
• Consider the OS/hardware settings
44

• Make sure you have enough RAM
– The active data should fit in the buffer pool
– MySQL connections and caches take memory
– Extra RAM for
• FS cache
• Monitoring
• RAM disk (tmpfs)
Hardware considerations
45

• Fast CPU is required for single threaded performance
• Recent servers have 32 to 80 cores.
• Enable hyper-threading
• MySQL now scales beyond 72 cores in 5.7
• Same core count in fewer sockets is better
• Faster cores better than more but slower cores
Hardware considerations
46

• Fast and reliable storage is good for IO bound loads
• HDD for sequential reads and writes
• Bus-attached SSD for random reads and writes
• Big sata or other disk for log files
• Several disks!
• Life time should be considered
Hardware considerations - Storage
47

• L of LAMP
• Good on Solaris
• Oracle invests on Windows
• For pure performance, favor Linux
Operating System
48

• I/O Scheduler
– Several Linux distributions use the CFQ scheduler by default
• OK for reads
• Serializes writes!
– NOOP and deadline are usually better for MySQL workloads
• Deadline is the default I/O scheduler for Oracle Linux
I/O settings on the operating system
49

• I/O Scheduler
– Check the current scheduler:
– Update the scheduler dynamically:
– To set at boot time, use the “elevator=deadline” boot option.
I/O settings on the operating system
shell# cat /sys/block/sda/queue/scheduler
noop deadline [cfq]
shell# echo deadline > /sys/block/sda/queue/scheduler
shell# cat /sys/block/sda/queue/scheduler
noop [deadline] cfq
50

• Linux glibc malloc can be a performance bottleneck
• Better to use alternative malloc library:
– tcmalloc
– jemalloc
Memory allocation library
51

• Set alternative malloc library:
– mysqld_safe
– systemd distributions:
• Set LD_PRELOAD in /etc/sysconfig/mysql
Memory allocation library
[mysqld_safe]
malloc-lib = /usr/lib64/libjemalloc.so.1
52

Summary
Wrapping it all up
53

Summary
• MySQL performance tuning is similar to all other performance tuning:
– Premature optimization is bad
– Only change one thing at a time and don’t make too large changes
– Don’t micro manage
– One size does not fit all
– Base your decisions on measurements
– Understand what an option does before changing it
– Understand your system (data)
– Understand what you need
– Consider the whole stack
54

Thank You
Q&A
55

6 Tips to MySQL Performance Tuning

6 Tips to MySQL Performance Tuning

More Related Content

What's hot (20)

Similar to 6 Tips to MySQL Performance Tuning (20)

More from OracleMySQL (7)

Recently uploaded (20)

6 Tips to MySQL Performance Tuning

Editor's Notes