Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • A lot of SSDs don't perform as well as people think they should because file systems haven't caught up with them yet. They are still trying to minimize seeks so they'll do extra processing that's unnecessary on SSDs.

    How big is your working copy (the majority of your database that you use at a time, with indexes, etc)? It might make more sense just to buy a ton of RAM if you can fit most of your working copy in memory.

    • by Wonko (9336) on 2009.11.10 14:01 (#71085)

      A good current gen SSD should provide a pretty reasonable boost in performance for a database. The most interesting, and my favorite, number I got out of benchmarking my Intel X25-M is that it can pull over 4000 seeks per second on my laptop. The cheap 4 disk RAID 10 in my web server only pulls a bit over 300.

      The thing slowing the DB tests down isn't just the disks. Its the ACID properties of the database. I'm sure MySQL is calling sync quite a bit. If it didn't, the OS disk caching would work nearly as well as the RAM disk. Every sync is going to require at least 1, but probably more, seeks. A good SSD would help out a lot there, but not nearly as much as a RAM disk should.

      I agree with mpeters. RAM is dirt cheap, buy lots of it and use RAM disks for testing.

      If you can't buy enough RAM and you're testing on Linux you might want to try tmpfs. tmpfs is memory+swap backed, and even when swapped is pretty fast. I can't imagine that tmpfs has to respect the sync calls.