In order to improve the performance of mysql when dealing with large databases, there's a couple of settings that can be tweaked in your my.cnf file (or through a MySQL administration tool). The following line has proven to be the most useful.
innodb_buffer_pool_size = 1G
I've been meaning to write about this improvement for the last few weeks, but I wanted to test it myself first. So far I'm very pleased with the performance improvement (database restore time is down from about 3 hours to about 45 minutes on a ~1.2G database). I haven't tested how this setting affects MySQL during normal execution, but it certainly helps improve performance during backups and restores. So if you find yourself backing up and restoring large MySQL databases, you should test this out. You should (obviously) not set innodb_buffer_pool_size to a value greater than the available memory on your machine.
Thanks to Marc Harrison for the tip.
If you want to read some more about this configuration, I found a couple of blog entries from a few years ago Enjoy!
http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/
http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/
Thursday, December 17, 2009
Wednesday, December 16, 2009
On setting up a development environment in Mac OS X 10.6 Snow Leopard
I just bought the new Mac Mini from Apple. It's my first Mac since the Mac Plus of the early 90's and I have to say ... it feels good to be back. I still love doing development on Ubuntu, but Mac OS X is easy to get used to and a lot of fun to play around with. Nothing compares to "apt-get install ..." (on Ubuntu) when getting a development environment set up, but this tutorial for Tomcat 6 probably saved me a couple of hours of agony of going it alone.
Thursday, December 3, 2009
Fixing an existing subversion project to migrate to the trunk/branches/tags convention
Here's the procedure I used to move an existing "dumb" subversion project to one that follows the subversion convention (trunk/branches/svn). It's a combination of the two ideas presented in the articles below. More steps then I was hoping for, but it's a pretty simple-to-follow solution and much less aggravating than the Eclipse approach.
(this procedure assumes that you are using Linux, but the process would be similar on Windows or Mac)
// 1. Checkout a fresh copy of your project
$ svn co http://svn.myproject.com/myproject myproject
// 2. Change directories to make it easier perform svn operations
$ cd myproject
// 3. Add the new trunk directory
$ svn mkdir trunk
// 4. Locate all files/dirs in the current directory and svn move them to the trunk directory
$ find . -maxdepth 1 ! -name trunk -exec svn mv '{}' trunk \;
// 5. Double check that all files have been svn move'd (.classpath, .project, build.xml, etc)
$ ls -la trunk
// 6. Commit all changes
$ svn ci -m "myproject: moving all files from myproject into myproject/trunk"
// 7. Switch your local copy of the module to
$ svn switch http://svn.myproject.com/myproject/trunk myproject
Resources:
(this procedure assumes that you are using Linux, but the process would be similar on Windows or Mac)
// 1. Checkout a fresh copy of your project
$ svn co http://svn.myproject.com/myproject myproject
// 2. Change directories to make it easier perform svn operations
$ cd myproject
// 3. Add the new trunk directory
$ svn mkdir trunk
// 4. Locate all files/dirs in the current directory and svn move them to the trunk directory
$ find . -maxdepth 1 ! -name trunk -exec svn mv '{}' trunk \;
// 5. Double check that all files have been svn move'd (.classpath, .project, build.xml, etc)
$ ls -la trunk
// 6. Commit all changes
$ svn ci -m "myproject: moving all files from myproject into myproject/trunk"
// 7. Switch your local copy of the module to
$ svn switch http://svn.myproject.com/myproject/trunk myproject
Resources:
Subscribe to:
Posts (Atom)