Best Practices for Messaging Server and ZFS

Best Practices for Messaging Server and ZFS

Update 10/14/09
This information needs to be updated to include the pros and cons of using ZFS.

ZFS provides the following features that make it ideal for backing up the Messaging Server message store:

  • Snapshot backup
  • Enables the use of less expensive SATA drives
  • Built-in volume manager that enables you to grow file systems dynamically

Topics:

Configuration Recommendations for ZFS and Messaging Server

  1. Separate the Messaging Server mboxlist database, message file, and index cache files on different file systems.
    The mboxlist database is a sleepycat database that contains mailbox meta data.
    The index cache records (store.idx and store.c*) contain meta information about mailboxes and messages. Messaging Server accesses and modifies this meta information, although the modifications tend to be more random and smaller. The location of the index cache records is controlled by the configutil parameter store.partition.partition_name.path, where partition_name is the name of the partition.
    Each message file (*.msg) represents a single email. Each message file is written to disk once, never modified, read many times (for example, when a user accesses the email, when the messages are backed up, and so on) and may be deleted. By default, these files are stored with the index and cache files. Message files location is controlled by the configutil parameter store.partition.partition_name.messagepath, where partition_name is the name of the partition.
    Separating the message files from the index cache records to different partitions (and underlying file systems) enables you to configure the file system with properties appropriate for the access type.
    Examples:
    # zfs create store/mboxlist
    # zfs set mountpoint=/var/opt/sun/comms/messaging/store/mboxlist store/mboxlist
    # zfs create store/primary-idx
    # configutil -o store.partition.primary.path -v /store/primary-idx
    # zfs create store/primary-msg
    # configutil -o store.partition.primary.messagepath -v /store/primary-msg

  2. Configure the index cache record file system to use the recordsize of 4 Kbytes.

    Starting with Messaging Server 7, the index recordsize is 128 bytes. (Messaging Server 5 and 6 used a smaller index record size). Cache recordsize is usually less than 2 Kbytes. The mboxlist database maximum page size is 8 Kbytes. The default ZFS recordsize is 128 Kbytes. Reducing the recordsize for these file systems can improve performance and reduce incremental snapshot backup size.

    Configure the index cache record file system to use 4 Kbytes recordsize and the mboxlist database file system to use 8 Kbytes recordsize.
    Examples:
    zfs set recordsize=4k store/primary-idx
    zfs set recordsize=8k store/mboxlist
    Note

    This setting controls the recordsize of newly created files only.


    The default recordsize of 128k is appropriate for the message store message file system.

  3. Disable file access time record.
    The message store does not utilize the file access time. By disabling file access time updates, you reduce unnecessary overhead.
    Examples:
    # zfs set atime=off store/mboxlist
    # zfs set atime=off store/primary-idx
    # zfs set atime=off store/primary-msg

  4. Keep ZFS pool space under 80 percent utilization to maintain pool performance.
    ZFS pool performance can degrade when a pool is very full. As the pool approaches 100 percent full, more time is needed to find free space and it is more likely that the free space is available only in small chunks.
    Configure the disk usage alarm threshold configutil parameter alarm.diskavail.msgalarmthreshold to at least 20, to receive a warning before the disk becomes full. (The default value is 10).
    Example:
    # configutil -o alarm.diskavail.msgalarmthreshold -v 20
    To enable message throttling sooner, configure the configutil parameter local.store.diskusagethreshold to 90.
    (The default is 99).
    Example:
    #configutil -o local.store.diskusagethreshold -v 90

ZFS Administration Recommendations

  • Perform snapshot backup regularly.
    Back up the mboxlist database, index, and message file systems atomically by using the zfs snapshot -r command. Then use the zfs send and receive commands, or an enterprise-level backup solution to save the data.
    Examples:
    # zfs snapshot -r store@now
    # zfs send store/mboxlist@now | ssh host2 zfs recv store/mboxlist
    # zfs send store/primary-idx@now | ssh host2 zfs recv store/primary-idx
    # zfs send store/primary-msg@now | ssh host2 zfs recv store/primary-msg
    You can use zfs send -i to perform incremental backups. Destroy the snapshots when they are not not needed.
    # zfs destroy -r store@now

Note that ZFS snapshots are for backing up and restoring the entire message store files system. You cannot back up and restore individual mailboxes. However, you can use imsbackup to back up the snapshot and imsrestore to restore the mailboxes.

Reference

http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide
http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide

Labels

messagingserver messagingserver Delete
zfs zfs Delete
wip wip Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jan 12, 2009

    shum says:

    >Could we recommend that the customer enable compression on the message file ...

    >Could we recommend that the customer enable compression on the message file partition as this would decrease I/O for >both writes and reads without adding too much CPU overhead since the compression overhead is primarily during >write/compression?

    I am not seeing performance impovement with compression enabled. If you have different results, please let us know.

  2. Feb 11, 2009

    alex9512 says:

    Using ZFS compression with the message partition may have unknown side effects. ...

    Using ZFS compression with the message partition may have unknown side effects. The upside is that it would save an incredible amount of space when applied to text messages. Not so much with jpg and mp3 data...

    CPU overhead would be incurred in the read AND write operation. It probably isn't too much of an issue with the write operation... However, there is a huge potential for delays and increased latency when a user reads their email. A good user experience is based on low latency and subsequent quick response times to queries. This would be especially ugly for a full body search across a users mail box. There may be special cases where SLAs would allow for a successful implementation, but in most cases I would not recommend it.

    We will be looking at this a bit as we continue to do storage testing for comms. In a couple of months we should be able to provide some data points for people to look at.

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Sun Microsystems community and they might not be employed or in any way formally affiliated with Sun Microsystems. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Sun nor any other party necessarily agrees with them.

Copyright 1994-2009 Sun Microsystems, Inc.
Powered by Atlassian Confluence
Sun Guidelines on Public Discourse Privacy Policy Terms of Use Trademarks Site Map Employment Investor Relations Contact