monitor some of the things
TRANSCRIPT
2013-10-18
MONITORSOME OF THE THINGS
Optimization, Backups, Replication, and more
Baron Schwartz, Peter Zaitsev &
Vadim Tkachenko
High PerformanceMySQL
3rd Edition
Covers Version 5.5
ME
• Cofounder of @VividCortex
• Author of High Performance MySQL
• @xaprb on Twitter
• http://www.linkedin.com/in/xaprb
RANT, RECAPPED
• The sky is falling
• Tools drive processes, and we need better tools designed for methods
• Pay attention to CAPS (Capacity, Availability, Performance, Scalability)
• Monitoring tools need to be a lot smarter
• Measure and monitor “work getting done”
HARD CAPACITY
• Disk volume
• CPU Cycles
• max_connections
• File descriptors, sockets, TCP port numbers, etc
• %used, absolute quantity available
SOFT CAPACITY
• Neil Gunther’s Universal Scalability Law
• %used, absolute quantity available
• Throughput, concurrency, errors
AVAILABILITY
• Availability is absence of downtime • %used, absolute quantity available
• Throughput, concurrency, errors
• MTBF, MTTR, MTTD, %availability
TASK PERFORMANCE
• Task performance is consistently fast response time.
• Measure an SLA in percentile response time per task, over observation intervals
• %used, absolute quantity available
• Throughput, concurrency, errors
• MTBF, MTTR, MTTD, %availability
• Response time, 95% response time
RESOURCE PERFORMANCE
• Resource performance is ability to run tasks consistently fast.
• %used, absolute quantity available
• Throughput, concurrency, errors
• MTBF, MTTR, MTTD, %availability
• Response time, 95% response time
• Throughput, concurrency, busy time, total response time, backlog/queue
SCALABILITY
• Universal Scalability Law again • %used, absolute quantity available
• Throughput, concurrency, errors
• MTBF, MTTR, MTTD, %availability
• Response time, 95% response time
• Throughput, concurrency, busy time, total response time, backlog/queue
STALL DETECTION
• Overloaded or underperforming? • %used, absolute quantity available
• Throughput, concurrency, errors
• MTBF, MTTR, MTTD, %availability
• Response time, 95% response time
• Throughput, concurrency, busy time, total response time, backlog/queue
• Utilization, saturation, errors, sources of load/demand
GIT ‘ER DONE
MONITOR WORK AND RESOURCES
WHAT NOT TO DO
• Don’t use top-N lists from Google
• Don’t just do what’s included in some Nagios plugin
№1TOP 10 LIST
1. MySQL availability2. Presence of insecure users and databases3. Aborted connects4. Error log5. Deadlocks6. Change in server configuration7. Slow query log8. Slave lag9. Percentage of maximum allowed connections10. Percentage of full table scans
№2TOP 10 LIST
1. Threads_connected2. Created_tmp_disk_tables3. Handler_read_first4. Innodb_buffer_pool_wait_free5. Key_reads6. Max_used_connections7. Open_tables8. Select_full_join9. Slow_queries10. Uptime
№1PLUGIN
1. threadcache-hitrate (Hit rate of the thread-cache) 2. slave-io-running (Slave io running: Yes) 3. slave-sql-running (Slave sql running: Yes) 4. qcache-hitrate (Query cache hitrate) 5. qcache-lowmem-prunes (Query cache entries pruned because of low memory) 6. keycache-hitrate (MyISAM key cache hitrate) 7. bufferpool-hitrate (InnoDB buffer pool hitrate) 8. bufferpool-wait-free (InnoDB buffer pool waits for clean page available) 9. log-waits (InnoDB log waits because of a too small log buffer) 10. tablecache-hitrate (Table cache hitrate) 11. table-lock-contention (Table lock contention) 12. index-usage (Usage of indices) 13. tmp-disk-tables (Percent of temp tables created on disk) 14. long-running-procs (long running processes)
№2PLUGIN
1. connection-time2. uptime3. threads-connected4. threadcache-hitrate5. q[uery]cache-hitrate6. q[uery]cache-lowmem-
prunes7. [myisam-]keycache-hitrate8. [innodb-]bufferpool-hitrate9. [innodb-]bufferpool-wait-free10. [innodb-]log-waits11. tablecache-hitrate
12. table-lock-contention13. index-usage14. tmp-disk-tables15. slow-queries16. long-running-procs17. slave-lag18. slave-io-running19. slave-sql-running20. sql21. open-files22. encode23. cluster-ndb-running
№3PLUGIN
SURFACE AREA
HTTP://WWW.FLICKR.COM/PHOTOS/NASAMARSHALL/5926864640/
DUPLICATE SIGNALS
• Queries
• Com_admin_commands
• Com_assign_to_keycache
• Com_alter_db
• Com_alter_db_upgrade
• Com_alter_event
• Com_alter_function
• Com_alter_procedure
• Com_alter_server
• Com_alter_table
• Com_alter_tablespace
• Com_alter_user
• Com_analyze
• Com_begin
• Com_binlog
• Com_ad_nauseum
DESIRABLE METRICS
• %used, absolute quantity available
• Throughput, concurrency, errors
• MTBF, MTTR, MTTD, %availability
• Response time, 95% response time
• Throughput, concurrency, busy time, total response time, backlog/queue
• Utilization, saturation, errors, sources of load/demand
Desirable Easy
Desirable Easy
IRRELEVANT
EXAMPLE PLEASE?
RESOURCE LIMITS
• Threads_connected near max_connections?
• %table cache used?
• Open file handles?
• Long-running queries/transactions?
ERRORS
• Deadlocks?
• Aborted connects?
AVAILABILITY
• Ability to connect and run a query?
• Uptime is small?
• Replication is running?
PERFORMANCE
• You can get throughput (Queries) and concurrency (Threads_running) from MySQL
• But in a Nagios check, no context to know whether they’re good or bad
• You generally can’t get response time, busy time, utilization, backlog, etc
• You can aggregate thread states, thread times, users, databases, query abstracts...
NAGIOS IS BEST AT
LIVING IN THE MOMENT
THOU SHALT NOT
• Cache hit ratios
• Thread cache hit ratio
• Buffer pool cache hit ratio
• Table cache hit ratio
• Key cache hit ratio
• Query cache hit ratio
• Rates of “bad” queries
• % temp tables on disk
• % full table scans
• % slow queries
• Unfixable things
• Replication delay
WHY NOT?
• Those are properties of the workload and application
• They are not conditions to alert/warn about
• They are not fixable / actionable in the service
ALERTS ARE
BETTER TOGETHER
QUESTION:
WHAT IS BETTER?
№1 ALERT!!!!!Disk CRIT 100% /dev/sda2
№2 ALERT!!!!!Replication CRIT Slave I/O Thread No
№3 ALERT!!!!!Replication CRIT Slave SQL Thread No
№4 ALERT!!!!!Replication CRIT Seconds_Behind_Master NULL
№5 ALERT!!!!!MySQL CRIT oldest transaction: 86400 seconds
- OR -
№1 ALERT!!!!!CRIT* Disk /dev/sda2 full* Replication stopped* Oldest transaction 86400 seconds* 4999 threads in status “Waiting for table metadata lock”
RESOURCES
• Chapter 3 of High Performance MySQL, 3rd Edition
• Percona White Papers
• Causes of Downtime in Production MySQL Servers
• Preventing MySQL Emergencies
• Goal-Driven Performance Optimization
• Forecasting MySQL Scalability with the Universal Scalability Law
• Method R: Optimizing Oracle Performance, Cary Millsap
• The Goal, Eli Goldratt
• The USE Method (Brendan Gregg) & his new book
• Guerrilla Capacity Planning, Neil J. Gunther
• Fundamental Performance & Scalability Instrumentation