We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Applying profilers to MySQL

Formale Metadaten

Titel
Applying profilers to MySQL
Untertitel
From PMP to perf, and why performance_schema is not a replacement in all cases
Serientitel
Anzahl der Teile
611
Autor
Lizenz
CC-Namensnennung 2.0 Belgien:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache
Produktionsjahr2017

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
While troubleshooting MySQL performance problems it is important to find outwhere CPU time is spent inside mysqld process. The process of investigationshould have as small influence as possible on the server we try totroubleshoot. Ideally, the source code should be instrumented for that. Performance_schema introduced in MySQL 5.5 is supposed to provide detailedenough instrumentation. But it comes with a cost, require careful sizing ofperformance counters, and the process of instrumenting the code is not yetcomplete even for MySQL itself, to say nothing about 3rd party storageengines, plugins and libraries like Galera. This is when profilers come handy. Poor Man's Profiler (PMP, aka pt-pmp), perfand oprofile on Linux can be easily used while studying MySQL performanceproblems. Basic usage steps are presented and several typical use cases arediscussed. In case of any performance problems with MySQL is important to find out whereCPU time is spent inside mysqld process. Is it waiting on disk I/O, some lockor internal mutex, or maybe it performs complex computation that should beoptimized? You can not figure out until you know how much time each importantstep takes, and how often it occurs. To investigate that, one may usedifferent tools and approaches, from tracing the code to using simple OS levelutilities that show disk and memory usage in total or per device, to moreadvanced programs that collect all kinds of information about specific programrunning (these are often called profilers). The process of investigationshould have as small influence as possible on the server we try totroubleshoot. Ideally, the source code should be instrumented for that and provide a"domain-specific" performance metrics. It may be not enough to know how muchtime specific function runs if its code is huge and complex.Performance_schema introduced in MySQL 5.5 was supposed to provide detailedenough instrumentation. But it comes with a cost (performance penalty, thatcan be notable), require careful sizing of performance counters, forceinvestigator to use advanced SQL to get the information needed. What's evenworse, the process of instrumenting the code is not yet complete even forMySQL itself, to say nothing about 3rd party storage engines, plugins andlibraries like Galera. This is when profilers come handy. During this talk we'll discuss the use ofPoor Man's Profiler (PMP, aka pt-pmp), perf and oprofile on Linux to studyMySQL performance problems. Basic usage steps are presented and severaltypical use cases are discussed. These including several famous bugs (likehttps://bugs.mysql.com/bug.php?id=68079), profiling for Galera, MyRocksstorage engine etc. Quick review of the most interesting MySQL bug reportswhere profilers played a key role in the investigation is also presented.