I am happy to announce Yasufumi Kinoshita joins our team as Performance Engineer. Yasufumi is known as InnoDB hacking expert, and there is bunch of patches he made we include in our releases: innodb buffer pool scalability fix, innodb rw_lock fix, control InnoDB IO etc. Actually there is one more patch -
“adaptive flush” in InnoDB, which makes flushing process more uniform and predictable. Yasufumi will post about this patch soon.

Yasufumi also had talk on MySQL Conference & Expo 2007
InnoDB Performance Potential in High-end Environments

Yasufumi’s primary tasks as you can guess will be InnoDB performance and scalability fixes, InnoDB improvements and related question, however we are not going to restrict his activity only to InnoDB area but for all MySQL related problems.

So expect more and better patches in near future.

Entry posted by Vadim | One comment

Add to: | | | |

The first public beta of WordPress 2.7 is here at last.  Join the thousands of people already testing 2.7 by downloading 2.7 Beta 1.  As previously mentioned on this blog, 2.7 is bringing a new visual design.  This design is almost completely implemented, but there are still a few areas that aren’t quite finished in Beta 1.  There are also several glitches in certain browsers.  Beta 1 provides the best experience in Firefox and Safari. Don’t worry, we are working on IE and Opera and will have those looking good in time for the final release.

Speaking of the final release, it will not be available on November 10th as originally scheduled.  We are two weeks behind schedule at the moment.  We need a little more time to finish the visual design, do a round of user testing against that finished design, and do a proper round of public beta testing. Our plan is to keep working as if Nov. 10 is still the release date.  However, instead of releasing the final 2.7 on the 10th, we will make a release candidate available instead.  The release candidate is intended to be a high-quality, almost-finished release that we are comfortable recommending for broad use.  After Nov. 10, the focus will be on fixing high impact bugs turned up by those of you testing the release candidate. I suspect 2.7 will be ready for final release by the end of November.  A specific date will be set as we progress through the public beta cycle and get a feel for how solid the release is.

Get WordPress 2.7 Beta 1.

Today we launched the WordPress Showcase, a display of some of the best and brightest WordPress users, who are using it to do a whole lot more than blog.

Pick your flavor and check out the possibilities available through WordPress MU, WordPress.com, WordPress.com VIP and WordPress.org.

Site screenshots are constantly updated, so what you see is a realtime look at what’s going on with our hottest users.

Don’t see something there that should be? Suggest an addition! We’ll check it out and add it to the bunch if we think it makes the cut.

When running InnoDB you are able to dig into the engine internals, look at various gauges and counters, see past deadlocks and the list of all open transactions. This is in your reach with one simple command -- SHOW ENGINE InnoDB STATUS. On most occasions it works beautifully. The problems appear when you have a large spike in number of connections to MySQL, which often happens when several transactions kill the database performance resulting in very long execution times for even simplest queries, or a huge deadlock.

In such rare cases SHOW ENGINE InnoDB STATUS often fails to provide the necessary information. The reason is that its output is limited to 64000 bytes, so a long list of transactions or a large deadlock dump may easily exhaust the limit. MySQL in such situation truncates the output so it fits the required size and obviously this is not good since you may lose some valuable information from your sight.

With large deadlocks you can actually deal by intentionally creating a new tiny deadlock which will replace the previous one in the output thus reducing the space occupied by that section of InnoDB status. Baron once wrote an article on how to do this.

There is not such easy way for the long transaction list, but fortunately there are some alternatives to the limited MySQL command output.

First one is that you can have innodb-status-file option set in your my.cnf. This will make InnoDB to write the full status output into innodb_status.<PID> file located in MySQL data directory. Unfortunately this is a startup time parameter, so unless you set it early, it will not be available in an emergency situation.

Other possibility is to create a special InnoDB table called innodb_monitor:

Creating it causes the full status to be periodically printed into MySQL error log. You can later disable logging by simply dropping the table. The problem I faced many times is that people do not configure their error log at all, so the messages disappear into nothingness. So what then?

I discovered that InnoDB will still create the status file on disk even if you do not specify innodb-status-file option. The file is actually used for every SHOW ENGINE InnoDB STATUS call, so whenever someone runs the command, InnoDB writes the output to that file first and then the stored information is read back to user. To make things more difficult, MySQL keeps the file deleted, so it is not possible access it with a simple cat filename or any other command through the file system. However on many systems such as Linux or Solaris, but possibly also others, there is a relatively simple way to access deleted but not-yet-closed files (file is physically removed only after it is no longer open by any process).

First be sure to run SHOW ENGINE InnoDB STATUS at least once. Then see what MySQL process ID is:

In my case the process ID is 11886, so I will be using it in the examples, but you should of course use whatever ps returned to you.

Now you can use /proc to see all the file descriptors that are being kept open by the process. So go to /proc/<PID>/fd and list all the files that were deleted.

The entries are presented as symbolic links from file descriptor number to a real path as in 12 -> /tmp/iblnLBhO.

One of these entries is what you are looking for, it's often (always?) the file with the lowest file descriptor number, so in my case it should be 5. But of course you can try reading a few first bytes from every such file to discover where InnoDB status is. You can also help yourself with lsof tool available for many platforms:

The 4th column contains file descriptor numbers and in the 7th column there are the file sizes. This makes it obvious that InnoDB status has to be under file descriptor 5 since it's the only non-zero length file.

So while you are still in /proc/<PID>/fd directory, you can try looking into that file:

Keep in mind the file will only be refreshed when you run SHOW ENGINE InnoDB STATUS command.

Entry posted by Maciej Dobrzanski | 3 comments

Add to: | | | |