At Percona we focus on education a lot, which we believe is critical for us to be successful with our mission of making businesses successful with their use of MySQL. The MySQL Performance Blog, our first effort in this space, by now contains over 1,000 technical articles.
There are times where you need to know exactly how much memory the mysqld server (or any other program) is using, where (i.e. for what function) it was allocated, how it got there (a backtrace, please!), and at what point in time the allocation happened.
For example; you may have noticed a sharp memory increase after executing a particular query. Or, maybe mysqld is seemingly using too much memory overall. Or again, maybe you noticed mysqld’s memory profile slowly growing overtime, indicating a possible memory bug.
I’ve written a lot about modeling MySQL with the USL, and I like it best of all the scalability models I’ve seen, but it’s not the only way to think about scalability. I was aware that New Relic supports a scalability chart, so I decided to take a peek at that. Here’s a screenshot of the chart, from their blog:
On January 16th at 10 AM Pacific/1 PM Eastern, I will give a webinar about the main traps that are awaiting you when designing and building a stable and high-performance MySQL application.
I will discuss a broad range of topics, from hardware and backups to instrumentation and indexing. I often see during my consulting practice wrong configuration putting data at risk or huge wastes of money to buy powerful hardware where a few indexes could have done the same result.
MySQL 5.6 seems to be ready for GA. I have no inside information about it, but from some clues collected in various places I feel that the release should not be far away. Thus, it's time for some serious testing, and for that purpose I have worked at updating MySQL Sandbox with some urgent features.