MySQL Performance Schema
Today we’re taking 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
in one of the 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).
So we’ve been hesitant about publicizing something that’s not
publicly available yet. But it’s working, internal tests show
few significant difficulties, so today I got the order to remove
the “Private=Yes” field value for the worklog task. That means
you’ll soon see the specification on forge.mysql.com (it’s WL#2360).
I’ll be blogging more about this each day for the next several days.
February 6th, 2009 at 12:23 am
[...] Peter Gulutzan just announced - we’re opening up a “new” worklog that we’ve been working on, Worklog [...]
February 10th, 2009 at 12:54 pm
Where’s a source tree with the code?
February 10th, 2009 at 7:45 pm
Everything for the performance schema feature is inside a source-code Bazaar tree. We’ll merge and make public in stages, probably after going through code review and QA.
The source code is not on launchpad at this time.