The MySQL 5.5.4-m3 beta version contains a number of
interesting new scalability features.

It contains the following InnoDB improvements:
Multiple Buffer Pool instances
- For example if the buffer pool is 8 GByte in size
the buffer pool can be split into 4 buffer pools
each containing 2 GBytes. Each page is mapped into
one and only one of these buffer pools.
Split Log_sys mutex
- We have ensured that the Log mutex and the buffer
pool mutex is more independent of each other. Also
the log_sys mutex is through this split less
contended.
Split out flush list from buffer pool mutex
Split Rollback Segment mutex into 128 instances
Separate Purge Thread from Master Thread
- Splitting out the purge thread from the master thread
is very important to ensure that performance is stable.
Extended Change buffering, now also Deletes and purges …

Today we have something to celebrate - the MySQL 5.5.4 was announced! And a huge number of performance improvement made in this version make me very happy :-))

I've got an immense pleasure to participate in this story and seek for the most optimal solutions together with all these talented engineers from MySQL/Sun/InnoDB/Oracle teams (and in few months all Oracle :-)) - and I think it was a huge step ahead to see how well we may all work together :-))

And now I'm happy to share with you my results obtained with MySQL 5.5.4 on dbSTRESS benchmark. All tests were executed on the 32cores Intel server running Fedora 10 and having 128GB RAM and absolutely fast internal SSD drives (and if from the memory I've used only 16GB for the buffer pools, the SSD drives helped a lot to reduce any dependency on the I/O activity).

Test scenario :

• Workload(s): Read-Only, Read-Write
• Sessions: 1, 2, 4, 8, 16, 32, 64, …

I am not sure when this will actually get posted online since I currently have no internet in my room. My one gripe (perhaps other than the chairs) about the conference is that the hotel does not offer free Internet and it is just expensive enough to cause me to use some discretion.

Be that as it may, day 1 was fun. Admittedly, some of the talk by Percona were things I already knew, though I did learn a few nice things (mostly about how to approach problems the right way since I do tend to jump into problems perhaps a bit prematurely at times). Some of the concepts Baron pointed out, while simply, are things I do not always think of when approaching a problem. I am almost excited to start putting such ideas to good use, in fact.

Likewise, the Drizzle talk, while quite interesting, went above my head. That is not saying much though since I have not touched C++ in a long time and have not really looked at the internals …

Since the Sun acquisition and the following announcement of the Oracle acquisition, the owner of MySQL have been fairly silent in terms of stated directions of MySQL.   This has allowed a lot of FUD to be spread throughout the user community.  At the MySQL users conference there are going to be some excellent keynotes helping customers get an update on MySQL technology.  It will be very

HTML 5 video is coming, but which codec is going to be used to deliver it?

Internet Explorer, Safari and Chrome have chosen on H.264, while Firefox and Opera are going for Ogg Theora. For us developers this sucks, because there is no one codec we can bet on to work in any browser. There's flash, which is more ubiquitous than any single browser, but it's a whole new toolchain to learn, and in my opinion it's a declining technology which will one day join the ranks of shockwave and <applet>. The future is in HTML, so what to do? Unfortunately there's no easy answer, so the most I can do is give an overview of what is going on today.

Choose multiple

First and foremost, keep in mind that the standard for the <video> tag allows multiple codes. You can easily specify a video tag with both an ogg vorbis and an H.264 source. This works as follows:

1. <video controls="true">
2. <source …

The newly released MySQL 5.5 beta version MySQL 5.5.4-m3
has a large number of significant performance improvements.
These improvements makes it possible for MySQL to scale
well even on 32-core servers. The graph below shows how
MySQL 5.5.4-m3 scales from 12 cores to 32 cores using a
single thread per core. The benchmark used here is
dbStress. dbStress uses a number of tables which spreads
the impact of mutexes and improves scalability.



The graph below shows a similar scalability analysis on a
smaller server where the benchmark used was Sysbench RW.
The red line shows the scalability of MySQL 5.1.45, the
green line shows scalability of MySQL 5.5.3-m3 and the
blue line shows MySQL 5.5.4-m3. So this graph shows that
even with …

One of the well known and much written about complaint regarding InnoDB recovery is that it does not scale well on high-end systems. Well, not any more. In InnoDB plugin 1.0.7 (which is GA) and plugin 1.1 (which is part of MySQL 5.5.4) this issue has been addressed. Two major improvements, apart from some other minor tweaks, have been made to the recovery code. In this post I’ll explain these issues and the our solution for these. First issue reported here is about available memory check eating up too much CPU. During recovery, the first phase, called redo scan phase, is where we read the redo logs from the disk and store them in a hash table. In the second phase, the redo application phase, these redo log entries are applied to the data pages. The hash table that stores the redo log entries grows in the buffer pool i.e.: memory for the entries is allocated in 16K blocks from the …

Performance Schema Support in InnoDB

With the plugin 1.1 release, InnoDB will have full support of Performance Schema, a new feature of MySQL 5.5 release. This allows a user to peak into some critical server synchronization events and obtain their usage statistics. On the other hand, in order to make a lot of sense of the instrumented result, you might need some understanding of InnoDB internals, especially in the area of synchronization with mutexes and rwlocks.

With this effort, the following four modules have been performance schema instrumented.

1. Mutex
2. RWLOCKs
3. File I/O
4. Thread

Almost all mutexes (42), rwlocks (10) and 6 types of threads are instrumented. Most mutex/rwlock instrumentations are turned on by default, a few of them are under special define. For File I/O, their statistics are categorized into Data, Log and Temp file I/O.

This blog is to give you a quick …

Background

The original motivation behind this patch was the infamous Bug#26590 – MySQL does not allow more than 1023 open transactions. Actually the 1024 limit has to do with the number of concurrent update transactions that can run within InnoDB. Where does this magic number come from ? 1024 is the total number of UNDO log list slots on one rollback segment header page. And in the past InnoDB created just one rollback segment header page during database creation. This rollback segment header page is anchored in the system header page, there is space there for 128 rollback segments but only one was being created and used resulting in the 1024 limit. Each slot in the rollback segment header array comprises of {space_id, page_no}, where both space_id and page_no are of type uint32_t . Currently the space id is “unused” and always …

Just a quick note that the InfiniDB team is at the MySQL show, so make sure you stop by our booth in the Exhibition Hall to say hi. Tonight is the Expo Hall reception, so grab some food and drink, and come on by to see a pretty cool demo we've got with lots of data that will show you what InfiniDB is capable of.  Hope to see you there!