Thought I would throw this out here so I remember it, and it maybe useful for someone else.  During a session here at Sun’s CEC conference one of the presenter was talking about setting CPU affinity for hardware interrupts.  This made me think of our hack ( workaround ) for innodb scalability on a 16 core machine ( set the mysqld affinity to cpu’s 0-7 or 8-15 ).   In order to get the top performance out of a 16 core machine we probably want to ensure everything else goes to the cpu’s not set to be servicing mysql.   So a quick google search came up with this article on setting the affinity for IRQ’s in the linux kernel.   So with a 16 core box, I could set the affinity for Mysqld to cpu’s 8-15, while setting the affinity of the interrupts to something in the 0-7 range.

You might be wondering what's been happening with MySQL performance since Sun arrived on the scene. The good news is that we haven't been idle. There's been general recognition that MySQL could benefit from some performance and scalability enhancements, and Sun assembled a cross-organizational team immediately after the acquisition to get started on it. We've enjoyed excellent cooperation between the engineers from both organizations.

This kind of effort is not new for Sun - we've been working with proprietary database companies on performance for years, with source code for each of the major databases on site to help the process. In this case, the fact that the MySQL engineers are working for the same company certainly simplifies a lot of things.

If you'd like to get some insight into what's been happening, a video has just …

You might be wondering what's been happening with MySQL performance since Sun arrived on the scene. The good news is that we haven't been idle. There's been general recognition that MySQL could benefit from some performance and scalability enhancements, and Sun assembled a cross-organizational team immediately after the acquisition to get started on it. We've enjoyed excellent cooperation between the engineers from both organizations.

This kind of effort is not new for Sun - we've been working with proprietary database companies on performance for years, with source code for each of the major databases on site to help the process. In this case, the fact that the MySQL engineers are working for the same company certainly simplifies a lot of things.

If you'd like to get some insight into what's been happening, a video has just …

You might be wondering what's been happening with MySQL performance since Sun arrived on the scene. The good news is that we haven't been idle. There's been general recognition that MySQL could benefit from some performance and scalability enhancements, and Sun assembled a cross-organizational team immediately after the acquisition to get started on it. We've enjoyed excellent cooperation between the engineers from both organizations.

This kind of effort is not new for Sun - we've been working with proprietary database companies on performance for years, with source code for each of the major databases on site to help the process. In this case, the fact that the MySQL engineers are working for the same company certainly simplifies a lot of things.

If you'd like to get some insight into what's been happening, a video has just …

If you are a MySQL 5.x/6.0 InnoDB replication user, right now you take a significant performance hit on the replication master simply by turning on the binlog. The good news is that we've taken a big step toward eliminating that performance gap. I'll describe the problem, how I was able to track down the root cause, and point to a patch that fixes the problem. Since the changes are in the InnoDB code, right now we're waiting on Oracle/Innobase to review the fix and formally commit it. Once that happens, you should see it show up in binary releases. In the meantime, if you build your own binaries you can test the prototype patch yourself.

One of the things I have been working on quite a bit over the past several months is scalability of the nodes within a MySQL scale-out replication environment.  The reason being that there has been a rapid …

If you are a MySQL 5.x/6.0 InnoDB replication user, right now you take a significant performance hit on the replication master simply by turning on the binlog. The good news is that we've taken a big step toward eliminating that performance gap. I'll describe the problem, how I was able to track down the root cause, and point to a patch that fixes the problem. Since the changes are in the InnoDB code, right now we're waiting on Oracle/Innobase to review the fix and formally commit it. Once that happens, you should see it show up in binary releases. In the meantime, if you build your own binaries you can test the prototype patch yourself.

One of the things I have been working on quite a bit over the past several months is scalability of the nodes within a MySQL scale-out replication environment.  The reason being that there has been a rapid …

If you are a MySQL 5.x/6.0 InnoDB replication user, right now you take a significant performance hit on the replication master simply by turning on the binlog. The good news is that we've taken a big step toward eliminating that performance gap. I'll describe the problem, how I was able to track down the root cause, and point to a patch that fixes the problem. Since the changes are in the InnoDB code, right now we're waiting on Oracle/Innobase to review the fix and formally commit it. Once that happens, you should see it show up in binary releases. In the meantime, if you build your own binaries you can test the prototype patch yourself.

One of the things I have been working on quite a bit over the past several months is scalability of the nodes within a MySQL scale-out replication environment.  The reason being that there has been a rapid …

As promised, here are the DBT2 results for the Intel SSD drive:

As you see the Intel drive blew away all the competition here… even besting another dbt2 score I got from a nice new shiny 8 disk raid 10 system.

Doing dbt2 tests on on the intel drive today…  One of the strange things I ran into last time testing out my memoright drive was running the RPM version of the enterprise binaries -vs- the tarball version seemed significantly faster.  I had some other folks try it on other hardware and they could never replicate the performance slowdown,.  Basically before I was getting 4407 TPM in DBT2 from the RPM (5.0.60) in Centos 5, while the tarball (5.0.60) was only hitting 2505 TPM.   This was consistant.  Now I see that my most recent run of dbt2 against the Intel SSD acheived 3600 TPM/s, which is lower then the rpm, but higher then the tarball ( this was achieved via tarball ).   As i said this difference has not been verified independently, and it could be any number of odd factors at play on my hardware.

I need to go back and figure this out again…   But on a positve note, apples to apples the intel ssd …