Performance Schema

A year ago we took the wraps off the best MySQL feature of 2009: Performance Schema. It monitors multitudinous low-level server events and provides them in tables inside a new “database” called, surprisingly, PERFORMANCE_SCHEMA. So far …

• It instruments mutex and disk io calls in the server and several storage engines.
• It times precisely (to the nearest cycle or nanosecond or microsecond or tick depending on user choice).
• It has tables for “current event” by thread (what the job is waiting for if it’s blocked).
• It has tables for “history of events” by thread (what were the last N mutex or file io activities, and where).
• It has summaries by thread (how many fractoseconds did this job spend on io since it started).
• It has summaries by object (how many times has somebody read from file X).

On any operating system, with really small overhead, continuously.

There’s a German saying “Erst Eier legen, dann gackern, nicht umgekehrt” (first lay eggs, then cackle, not the other way around). But this has now gone through the proposal stage, the architecture review, the coding, the code reviews by 6 engineers, the QA, and the documentation. It’s in the milestone now which we named “Celosia”.

This is the chance to find out about the roadmap from the architect of these tasks in the MySQL worklog:

WL#2360: Performance Schema

WL#2373: Use cycle counter for timing

WL#2515: Performance statements

WL#3249: SHOW PROCESSLIST should show memory

WL#4674: PERFORMANCE_SCHEMA Setup For Actors

WL#4678: PERFORMANCE_SCHEMA Instrumenting File IO

WL#4813 PERFORMANCE_SCHEMA Instrumenting Stages

WL#4816: PERFORMANCE_SCHEMA Summaries

WL#4895: PERFORMANCE_SCHEMA Instrumenting Table IO

WL#4878: PERFORMANCE_SCHEMA Trace

WL#4896: PERFORMANCE_SCHEMA Instrumenting Net IO