Backup strategy for large mailbox stores

[Dietmar Rieder]

On 02/19/2010 04:50 PM, Eric Luyten wrote:
> On Tue, February 16, 2010 9:49 am, Eric Luyten wrote:
> <...>
>> ZFS is awesome.
>>
>>
>> We have a ZFS pool composed of nine LUNs on an iSCSI-connected (2 x 1 Gbps)
>> EMC Celerra. All disks are 7200 rpm S-ATA.
>>
>>
>> On our previous storage system (FC-AL connected StorageTek with 15k and 10k
>> rpm FC disks) I was able to run more finds/dumps/... in parallel without
>> impacting mail service performance or message delivery rate.
>>
>> Even now I can pull close to 100 MB/s from the mail section of the storage
>> subsystem without users noticing.   48 GB RAM on the mailserver sure helps,
>> plenty of ARC :-)
>
>
> (thought I'd share this with you lot :-)
>
>
> Yesterday morning our mail server suffered a severe slowdown, leading to
> hundreds of IMAP and POP clients hitting various timeouts, users getting
> upset and starting to call helpdesks (offices down my hallway).
>
> All filesystems appeared sluggish at Solaris level while the iSCSI network
> links and the SAN were only moderately loaded. Weird.
>
> Luckily I had recently read (on info-cyrus ? cannot find the article right
> now) about a "ZFS>  80%" condition.

I guess you are talking about:
http://lists.andrew.cmu.edu/pipermail/info-cyrus/2010-January/032337.html

>
> Our Z pool was 83% full ...
> Deleted the December snapshots, which brought that figure down to 74%
>
> Performance came right back  :-)

That's what we observed, it's sad because you virtually loose 20% of you 
capacity and if you have a multi-terabyte volume/pools it can be a lot! 
But since a lot of the IO is done on the meta data and the dbs in 
"configdirectory" (which is not very large) it helps to have them on 
volumes/pools separated from the imapspool.

Didi