You are currently browsing the daily archive for February 28, 2009.


[Update – 3/19/2009: Read The SSD Anthology: Understanding SSDs and New Drives from OCZ (on AnandTech) if you are thinking of buying an SSD. There’s useful information in a discussion of the article over at Hacker News].

Because disk i/o is one of the primary factors affecting the performance of GemStone/S applications, using SSD drives has been an intriguing proposition ever since they popped onto the scene.

About a week ago, Otto Behrens posted a message on the GemStone Mailing list (emphasis mine):

I’m supporting a GS/S 32 bit system at an investment / insurance company. The database is currently 16GB and runs about 40 concurrent sessions.

I recently bought a 80GB Intel® X25-M Mainstream SATA Solid-State
Drive (SSD) and installed it on a Windows XP desktop (Pentium 4, 1.2GB
RAM). I set up a 512MB SPC and copied (all!) the extent files onto the
, leaving tranlogs on the internal IDE. This machine outperforms
the production environment significantly! OK, the production
environment is a Sun with 2 x 1GB CPUs and 8 GB RAM; the GemStone DB
there is set up with an SPC of 3GB.

Anybody tried this with GS/S? I think it will be significant because
the SSD is perfectly suitable for this kind of database. Because of
all the random reads done on these databases, the biggest bottleneck
have always been the seek time on magnetic disks. The SSD reduces seek
time to practically zero! The net result is that we need a much
smaller SPC and can simply use internal SATA disks
. Well, let’s see
first, but I can see much cheaper hardware with much better
performance coming…

And yesterday, Hernan Wilkinson wrote in a message (emphasis mine):

Hi Otto, after your mail we decided to give the SSD a try, and what can I
say… thank you very much for sharing your experience with all of us!

We bought a Super Talent Master Drive OX ( that
has 150 MB/Sec (max) of Seq. Read, 100 MB/Sec (max) of Seq. Write and 0.1 ms
of access time. As you can see, it is slower than the Intel X25-M and the
results are just outstanding.

Here are some numbers of one of the migration’s step we have to run in a
couple of weeks in one customer. The customer’s extent is about 3.5 Gb. The
process was run in the same machine with the same GemStone configuration (we
just changed the path of the extent and transaction log files to point to
the SSD drive). The hard drive is a Maxtor stm3250310as ( 300 MB/s of data
transfer rate and 11 ms of average seek time). The machine has an Intel Core
2 Duo of 3.0 GHz and 2 Gb of ram (600 MB of SPC), running Windows XP, SP3:

* Looking for all instances of 8 classes:
* With the hard drive: 28 minutes, 47 seconds
* With the SSD drive: just 39 seconds!!

* Migration total time:
* With the hard drive: 35 hours, 32 minutes, 3 seconds
* With the SSD drive: just 58 minutes, 28 seconds!!

So the difference is really big. We are thinking about telling our customers
to switch to this type of disk.

That’s a 30X performance gain achieved by installing SSD drives!

What’s going on?

If the Shared Page Cache (SPC) is too small relative to your working set, performance will be limited by how fast data pages can be read from disk.

If dirty pages are created too fast (high commit rate and/or high data volume), performance will be limited by how fast data pages can be written to disk.

Even if a system runs at an acceptable rate, its equilibrium can be upset by maintenance activities such as:

  • Garbage Collection which involves an increased level of page reads, while all object in the repository are scanned, and an increased level of page writes while the dead objects are disposed and pages are reclaimed.
  • Data Migration which involves an increased level of page reads, while allInstances are collected, and an increased level of page writes as each instance is migrated to it’s new shape.

The page read problem is generally solved by increasing the size of the SPC (GS/S 32bit SPC is limited to ~4GB). With an SSD drive, read rates are significantly faster so that you can see significant performance gains without changing the size of the SPC. This means you should be able to allocate your excess RAM to OS processes (like more and/or larger VMs).

The page write problem is generally solved by spreading the extent files across multiple disk spindles and adding additional  AIO Page Servers. With an SSD drive, write rates are significantly faster so that you don’t need multiple AIO Page Servers (and multiple disk spindles) to keep up with the generation of dirty pages. This means that you don’t have to add external drives to supply the needed spindles.

I haven’t gotten my hands on an SSD drive yet, but with the kind of results that Otto and Hernan have seen it looks like SSD drives should receive serious consideration when you are looking to squeeze more performance from your GemStone/S application.

[1] Photo by Éole Wind (Creative Commons).

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 446 other followers


Top Posts

RSS GLASS updates

  • An error has occurred; the feed is probably down. Try again later.

RSS Metacello Updates

  • An error has occurred; the feed is probably down. Try again later.

RSS Twitterings

  • An error has occurred; the feed is probably down. Try again later.
February 2009