dovecot - Jan 2011 - SSD drives are really fast running Dovecot

I just replaced my drives for Dovecot using Maildir format with a pair 
of Solid State Drives (SSD) in a raid 0 configuration. It's really 
really fast. Kind of expensive but it's like getting 20x the speed for 
20x the price. I think the big gain is in the 0 seek time.

Here's what I bought.

Crucial RealSSD C300 CTFDDAC256MAG-1G1 2.5" 256GB SATA III MLC Internal 
Solid State Drive (SSD) 
<http://www.newegg.com/Product/Product.aspx?Item=N82E16820148349>

    *   2.5"
    *   256GB
    *   SATA III

    * *Sequential Access - Read:* 355MB/sec (SATA 6Gb/s) 265MB/sec (SATA
      3Gb/s)
    * *Sequential Access - Write:* 215MB/sec (SATA 6Gb/s) 215MB/sec
      (SATA 3Gb/s)
    * *Power Consumption (Active):* 2.1W READ, 4.3W WRITE
    * *Power Consumption (Idle):* 0.094W

Running it on an Asus motherboard that supports SATA III - 6 core AMD 
CPU and 16 gigs of ram. Might be slightly off topic but this server screams!

Quoting Marc Perkel <marc at perkel.com>:
>> I just replaced my drives for Dovecot using Maildir format with a
>   > pair of Solid State Drives (SSD) in a raid 0 configuration. It's
>   > really really fast. Kind of expensive but it's like getting 20x
the
>   > speed for 20x the price. I think the big gain is in the 0 seek time.
>   >
>   > Here's what I bought.
>   >
>   > Crucial RealSSD C300 CTFDDAC256MAG-1G1 2.5" 256GB SATA III MLC
>   > Internal Solid State Drive (SSD)
>   >
<http://www.newegg.com/Product/Product.aspx?Item=N82E16820148349>
>   >
>   >? ? *? ?2.5"
>   >? ? *? ?256GB
>   >? ? *? ?SATA III
>   >
>   >? ? * *Sequential Access - Read:* 355MB/sec (SATA 6Gb/s) 265MB/sec
(SATA
>   >? ? ? 3Gb/s)
>   >? ? * *Sequential Access - Write:* 215MB/sec (SATA 6Gb/s) 215MB/sec
>   >? ? ? (SATA 3Gb/s)
>   >? ? * *Power Consumption (Active):* 2.1W READ, 4.3W WRITE
>   >? ? * *Power Consumption (Idle):* 0.094W
>   >
>   > Running it on an Asus motherboard that supports SATA III - 6 core
AMD
>   > CPU and 16 gigs of ram. Might be slightly off topic but this server
>   > screams!
Hey Marc,

Just for testing purposes, what does a dd speed test give you?

http://it.toolbox.com/blogs/database-soup/testing-disk-speed-the-dd-test-31069
IMHO, the key part is exceeding the RAM size, but for a "closer to
Maildir" comparison, a decent file size that exceeds the drive cache is
good too..

Rick

> I just replaced my drives for Dovecot using Maildir format with a pair of
> Solid State Drives (SSD) in a raid 0 configuration. It's really really
fast.
> Kind of expensive but it's like getting 20x the speed for 20x the
price. I
> think the big gain is in the 0 seek time.

I thought about doing this on my email server since its troubles are
mostly disk I/O saturation but I was concerned about reliability.
Have heard that after so many read/writes SSD will go bad.  There are
an awful lot of read/writes on an email server.

I will be interested to hear how it stands up for you.

On 1/12/11 , Jan 12, 9:53 AM, Marc Perkel wrote:
> I just replaced my drives for Dovecot using Maildir format with a pair
> of Solid State Drives (SSD) in a raid 0 configuration. It's really
> really fast. Kind of expensive but it's like getting 20x the speed for
> 20x the price. I think the big gain is in the 0 seek time.
I've been considering getting a pair of SSDs in raid1 for just the
dovecot indexes. The hope would be to minimize the impact of pop3 users
hammering the server. Proposed design is something like 2 drives (ssd or
platter) for OS and logs, 2 ssds for indexes (soft raid1), 12 sata or
sas drives in RAID5 or 6 (hw raid, probably 3ware) for maildirs. The
indexes and mailboxes would be mirrored with drbd. Seems like the best
of both worlds -- fast and lots of storage.

Does anyone run a configuration like this? How does it work for you?

Anyone have any improvements on the design? Suggestions?

Matt put forth on 1/12/2011 1:15 PM:
> I thought about doing this on my email server since its troubles are
> mostly disk I/O saturation but I was concerned about reliability.
> Have heard that after so many read/writes SSD will go bad.  There are
> an awful lot of read/writes on an email server.
From:  http://www.storagesearch.com/ssdmyths-endurance.html

"As a sanity check - I found some data from Mtron (one of the few SSD oems
who
do quote endurance in a way that non specialists can understand). In the data
sheet for their 32G product - which incidentally has 5 million cycles write
endurance - they quote the write endurance for the disk as "greater than 85
years assuming 100G / day erase/write cycles" - which involves overwriting
the
disk 3 times a day."

That was written in 2007.  SSD flash cell life has increased substantially in
the 3-4 year period since.
>From a flash cell longevity standpoint, any decent SSD with wear leveling is
going to easily outlive the typical server replacement cycle of 3-5 years, and
far beyond that.  Note that striping two such SSDs (RAID 0) will double the wear
cycle life, and striping 4 SSDs will quadruple it, so that 85 years becomes 340+
years of wear life with a 4 SSD stripe (RAID 0).

Your misgivings about using SSDs are based on obsolete data from many years ago.

-- 
Stan

On Wed, 2011-01-12 at 09:53 -0800, Marc Perkel wrote:
> I just replaced my drives for Dovecot using Maildir format with a pair 
> of Solid State Drives (SSD) in a raid 0 configuration. It's really 
> really fast. Kind of expensive but it's like getting 20x the speed for 
> 20x the price. I think the big gain is in the 0 seek time. 
You may find ramfs is even faster :)

I hope you have backups.

-- 
dwmw2

On Sat, 15 Jan 2011, Charles Marcus wrote
> Doing this will also help train users in proper email management -
> treating their INBOX just like they would a physical INBOX tray on their
> desk. They wouldn't just let paper pile up there, why do so in their
> INBOX (because they 'can')? Ie, it should be something they should
> always strive to keep totally EMPTY. Of course this practically never
> happens, but the point is, they need to learn to make a decision once
> they are finished with it, and most importantly, take said action -
> either delete it, or file it.
This is pretty much what I do with the mail domain I administer.  I've
set the INBOX with a modest quota, and a personal mail folder with a
generous quota.  I encourage users to keep their INBOX as a "working
set",
and archive the rest using any method they prefer.

It forces users to process their Email (or at least their INBOX).
and keeps packratting in check.  Super-big INBOX quotas seem to encourage
wasteful habits.  I've helped some users clean out their mailboxes and
was surpised at the amount of junk being kept for years and years.

Apart from a few users moaning about their meager INBOX, this policy
works out fairly well.

Joseph Tam <jtam.home at gmail.com>