The Anti-Blog Blog: Everyday Engineering and Architecture

This blog entry was triggered by Neelakanth's on MySQL InnoDB ZFS Best Practices post.

There's always a running debate about "best practices" and I know several people that say, "there are no *best* practices, only good or better practices".

So what are some of the settings for the Sun Messaging product and ZFS?
Han Shum has a post on the Comms Wiki for Configuration Recommendations for ZFS and Messaging Server
It covers the following including instructions:

• Separate the mailstore mailbox partitions (data) from the database files (indices)
• Match ZFS recordsize with page size (8 kb for mbox database, 4 kb for database index files and default of 128k for the actual message store file system)
• Disable File Access Time record
• Stay below 80% space utilization
  

Going beyond those things and considering what Neelakanth wrote, the following things are worth investigating at your own risk*:

• Use a Seperate ZFS Intent Log (slog) - Messaging is definitely write intensive and we've seen some improvements by moving the Intent Log off onto separate drives
• Make sure the ZFS Adaptive replacement cache (ARC) is enabled
• Make sure that the ZFS prefetch is enabled
• Consider using an SSD as L2ARC, SLOG or for the messaging database files / indices
• Determine if your storage is ZFS Write Cache friendly or not -- some storage devices / systems that have NVRAM interpret ZFS's command to flush the write cache in different and un-performance friendly ways. If your storage device has battery backed caches, consider turning off the ZFS cache flush

* There's no good substitution for doing this on a non-production environment that's configured with the same OS levels and patches as production!

I know the invites have been emailed but I thought I would post an invitation here as well...

More details and the registration form at:

https://www.suneventreg.com//cgi-bin/register.pl?EventID=2708

DATE: Tuesday, April 28, 2009

TIME: 9:00 AM Pacific // 12 NOON Eastern

AGENDA (ALL TIMES IN PACIFIC TIME)

9:00 AM To 9:10 AM Welcome, Introductions, & Agenda

9:10 AM To 9:30 AM What's New in Comms R6 Update 2 Jeff Allison, Product Mgr., Messaging Server

9:30 AM To 9:50 AM Mobile Device Update Marc Daniels, Technical Prod Mgr, Comms Suite

9:50 AM To 10:10 AM Comms R6 Best Practices Greg Balmer, Sr. Architect, Deployment Engineering

10:10 AM To 10:30 AM Convergence Update and Best Practices Arindam Chakraborty, Product Mgr., Convergence

10:30 AM To 10:40 AM Roadmap Update Jeff Allison, Product Mgr., Messaging Server

10:40 AM To 10:55 AM User Roundtable

10:55 AM To 11:00 AM Close, Next Steps

At a recent Sun Communications User Group meeting in Chicago, IL, one of my customers showed off their web-based tool to monitor the Sun Messaging Server.

It wasn't fancy but it was useful. It was a series of scripts and cron jobs calling the scripts to gather data that mostly came from 'counterutil', 'immonitor-access', 'imsimta' and 'imslog.pl' parsing script. The data is consolidated on an NFS server. A web application written in PHP / Perl parses and presents the data.

You can see visually if things are working. You can double-click and drill down to the next level... moving from Service to Server to Daemon to see where exactly the issue is or at least where it is in the system.

They figure this little application alone allows them to keep their staff lean-and-mean, plus solve issues before they become major problems. They can see what's happening as it happens pretty much.

They've used Big Brother and use Orca for things as well (mainly Solaris stats), but rather than use something that's overkill, they determined their requirements and wrote something.

I'm trying to encourage them to open it and make it a SourceForge project. Right now it's pretty proprietary and has data about their environment coded in it (a bit).

Staytuned!

Sun Microsystems (Skyline Room), Itasca, Illinois, United States

Please join Sun Microsystems for the Chicago area Comms User Group meeting. (This meeting is free of charge. Complimentary breakfast and lunch will be provided.) The Communication and Collaboration User Group consists of users of Sun Java System Calendar Server, Sun Java System Messaging Server, Sun Java System Instant Messaging, Communication and Collaboration.

https://www.suneventreg.com//cgi-bin/register.pl?EventID=2048