One of InnoDB’s features is that memory allocated for internal tables definitions is not limited and may grow indefinitely. You may not notice it if you have an usual application with say 100-1000 tables. But for hosting providers and for user oriented applications ( each user has dedicated database / table) it is disaster. For [...]
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 [...]
MySQL for Hosting Providers – how do they manage ?
November 28, 2008 By 15 Comments
Working with number of hosting providers I always wonder how do they manage to keep things up given MySQL gives you so little ways to really restrict how much resources single user can consume. I have written over a year ago about 10+ ways to crash or overload MySQL and since that people have come [...]
How Percona does a MySQL Performance Audit
November 24, 2008 By 17 Comments
Our customers or prospective customers often ask us how we do a performance audit (it’s our most popular service). I thought I should write a blog post that will both answer their question, so I can just reply “read all about it at this URL” and share our methodology with readers a little bit. This [...]
Google’s user_statistics V2 port and changes
September 12, 2008 By 9 Comments
Recently Google published V2 release of patches, one of them user_statistics we use in our releases. New features are quite interesting so we decided to port it to fresh releases of MySQL. Features includes: New statistics per user (Cpu_time, Bytes_received, Bytes_sent, etc) New command SHOW CLIENT_STATISTICS, which shows statistics per client’s hostname, not per user [...]
The #1 mistake hosting providers make for MySQL servers
July 25, 2008 By 30 Comments
This article is not meant to malign hosting providers, but I want to point out something you should be aware of if you’re getting someone else to build and host your servers for you. Most hosting providers — even the big names — continue to install 32-bit GNU/Linux operating systems on 64-bit hardware. This is [...]
Is DNS the Achilles heel in your MySQL installation?
May 31, 2008 By 16 Comments
Do you have skip_name_resolve set in your /etc/my.cnf? If not, consider it. DNS works fine, until it doesn’t. Don’t let it catch you off guard. Do you really need to restrict MySQL users based on hostnames? If you don’t, you should probably disable this feature of MySQL’s authentication system. You never know when your hosting [...]
MySQL extensions for hosting
April 24, 2008 By 11 Comments
A few weeks ago I was asked to isolate some functionalities from Mark Callaghan’s MySQL patch bundle. They were extensions adding per-user and per-table accounting to the database, accessible with a new set of commands such as SHOW TABLE_STATISTICS, SHOW INDEX_STATISTICS and SHOW USER_STATISTICS. The first two can interest anyone to periodically check what data [...]
10+ Ways to Crash or Overload MySQL
November 13, 2007 By 20 Comments
People are sometimes contacting me and asking about bugs like this which provide a trivial way to crash MySQL to the user with basic privileges and asking me what to do. My answer to them is – there is nothing new to it and they just sit should back and relax Really – there are [...]
Traffic Tricks by Hosting Providers.
October 17, 2007 By 13 Comments
I already wrote once about hosting troubles which we had with this site a while back. Today we had another trouble to one of the European hit servers for ClickAider project. We had purchased this 1and1 server few months ago, before we were running into troubles and as it was running well and because we [...]
