[Building Sakai] innodb plugin

[Charles Hedrick]

Our mysql server does almost no I/O, so I haven't been looking at ways to improve that. Our current I/O system can do way more IOPS than we're ever likely to need. 

I was mostly interested in whether anyone has tried to enough to know whether there are any compatibility issues. I have seen XtraDB. Knowing that you're using it with Sakai is useful.


On Dec 16, 2011, at 12:24 PM, Sam Ottenhoff wrote:

> Yes, InnoDB plugin should be superior to InnoDB because of ability to utilize multiple IO theads.
> 
> We use XtraDB from Percona: http://www.mysqlperformanceblog.com/2010/01/13/innodb-innodb-plugin-vs-xtradb-on-fast-storage/
> 
> We also make use of the FusionIO cards (SLC) referenced in the post.
> 
> --Sam
> 
> On Thu, Dec 15, 2011 at 8:11 PM, Charles Hedrick <hedrick at rutgers.edu> wrote:
> Is anyone running with the Innodb plugin? I"m testing our a new database server. I duplicated a problem that I saw on our production server, although only when I was load testing. I simulated 200 students starting a test at the same time, using the direct link into the test. This turns out to be much worse than one would hope, because a critical table isn't indexed.
> 
> WIth 100 users the test on the new system took 2 min, but only if I told innodb to use only 8 threads. This is a VM that has 18 virtual cores (hyper threaded system). No matter how many threads I used, CPU stayed at 33% or below, and there were periods of zero.
> 
> My reading is that there is contention, which is of course a known issue with Innodb on multicore processors. I've never seen that pattern of < 95% usage on our production server, which is an 8 core physical system (hyper threading off) running Solaris 10.
> 
> I decided to enable the innodb plugin. This is a two-line change to my.cnf. It uses a loadable library rather than the built-in innodb code. There should be no incompatibilities as long as you don't move to the new table format. The result was that my test used 95% of the CPU and took 19 sec.
> 
> This is clearly the way to go, if it doesn't cause trouble. Unless we see a performance disaster and have to move to the new configuration (which is possible), I'm going to keep the new database server in testing for a while, probably until Spring break.
> 
> The new server is part of our new fully virtualized infrastructure. It's on a new dual Westmere system (6 cores each), hyper threading on, Ubuntu server under Xenserver, with 3/4 of the cores assigned to this VM. File storage is a Dell MD3600i iSCSI system, connected with 10 G Ethernet.
> 
> We're already using Xenserver for our production front ends. The database systems are next.
> 
> 
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20111216/f757d3eb/attachment.html