After compiling Percona Server with TokuDB, of course I wanted to compare InnoDB performance vs TokuDB. I have a particular workload I’m interested in testing – it is an insert-intensive workload (which is TokuDB’s strong suit) with some roll-up aggregation, which should produce updates in-place (I will use INSERT .. ON DUPLICATE KEY UPDATE statements [...]
Find and remove duplicate indexes
June 20, 2012 By 9 Comments
Having duplicate keys in our schemas can hurt the performance of our database: They make the optimizer phase slower because MySQL needs to examine more query plans. The storage engine needs to maintain, calculate and update more index statistics DML and even read queries can be slower because MySQL needs update fetch more data to [...]
Bug#12704861
November 20, 2011 By 1 Comment
As Mark pointed out, there isn’t a lot of detail in the release notes about what could potentially be a very serious problem that is fixed in MySQL 5.1.60. I’ll repeat here the full documentation from the release notes: “InnoDB Storage Engine: Data from BLOB columns could be lost if the server crashed at a precise [...]
Scalr and MNPP
April 28, 2011 By Leave a Comment
Good news for all Percona Software users out there. There are more ways how you can get access to Percona Software. If you’re using Scalr (See also Scalr Project on Google Code) you might be interested in Percona Server roles support Scalr team has announced recently. If you’re Mac user and looking for complete development [...]
How to debug long-running transactions in MySQL
March 8, 2011 By 6 Comments
Among the many things that can cause a “server stall” is a long-running transaction. If a transaction remains open for a very long time without committing, and has modified data, then other transactions could block and fail with a lock wait timeout. The problem is, it can be very difficult to find the offending code [...]
Logging MySQL queries from the client instead of the server
February 2, 2011 By 2 Comments
The “slow query log” is the single most valuable way to examine query execution on your MySQL server. Queries are logged with timing information, and in the case of Percona Server, a great deal of additional performance and other diagnostic information. But the execution time recorded in the log is the time the query took [...]
Gathering queries from a server with Maatkit and tcpdump
July 1, 2009 By 23 Comments
For the last couple of months, we’ve been quietly developing a MySQL protocol parser for Maatkit. It isn’t an implementation of the protocol: it’s an observer of the protocol. This lets us gather queries from servers that don’t have a slow query log enabled, at very high time resolution. With this new functionality, it becomes [...]
5.0.75-build12 Percona binaries
January 23, 2009 By 18 Comments
After several important fixes to our patches we made binaries for build12. Fixes include: Control of InnoDB insert buffer to address problems Peter mentioned http://www.mysqlperformanceblog.com/2009/01/13/some-little-known-facts-about-innodb-insert-buffer/, also check Bug 41811 to see symptoms of problem with Insert buffer. http://www.percona.com/docs/wiki/patches:innodb_io_patches * innodb_flush_neighbor_pages (default 1) – When the dirty page are flushed (written to datafile), this parameter determines [...]
Using Multiple Key Caches for MyISAM Scalability
November 26, 2008 By 8 Comments
I have written before – MyISAM Does Not Scale, or it does quite well – two main things stopping you is table locks and global mutex on the KeyCache. Table Locks are not the issue for Read Only workload and write intensive workloads can be dealt with by using with many tables but Key Cache [...]
New SpecJAppServer results at MySQL and Sun.
November 12, 2008 By Leave a Comment
As you likely have seen Sun has posted the new SpecJAppServer Results More information from Tom Daly can be found here These results are quite interesting for me as I worked on some of the previous SpecJAppServer Benchmarks several years ago while being employed by MySQL. These are great results, plus they can be relevant [...]
