[p4] has anyone used a RAM-SAN?

[Tyler, Tom]

Hello!

   Monster has been running on solid state RAM drives for several years, and Ramsans for about the last two.  We love them!  After some fairly deep analysis, we determined we had a performance bottleneck on I/O, specificly for the filesystem where the Perforce databases were.  We had the depots (RCS archives) on separate filesystems.  Our analysis showed that the I/O needs of the filesystem where the database lived was between 10x and 100x greater than that of the depots.  So we came up with a solution to use solid state RAM drives on the filesystem where the Perforce databases were, to take advantge of the wicked fast I/O.  The overall performance improvement was quite drastic due to the exceptional throughput of solid state drives.

We experienced no issues with locking or any of the potention concerns you need to think about when considering an exotic type of filesystem.  We were on the lookout for such things, from having seen warnings about such things on other filesystem types at presentations at Perforce user conferences, but were lucky to experience no issues.

One key point -- BE SURE TO KEEP YOUR JOURNAL ON A DIFFERENT FILESYSTEM THAN YOUR DATABASES!!!  This is a best practice in any case, but is especially important when you're using solid state RAM drives, even if they are RAIDed.  We have had no issues with our Ramsan disk drives, but prior to using Ramsans, we had been using Platyplus solid state RAM drives.  The vendor for those had gone out of business, and we had been planning to replace the near-end-of-life equipment when a fan failure caused loss of the drive.  We didn't lose any Perforce data because we had the checkpoint from the night before, and the journal on a separate filesystem.  So all ended well after several hours of downtime while the old Platypus drives were replaced with Ramsans.  As collateral benefit, the Ramsans were even faster than the prior solid state drives, and better still, were supported by a happy vendor that's still in business.  The moral of the story:  Heed the Perforce recommendation to keep your journal on a different filesystem than your databases, even if you have RAID on that filesystem.  RAIDs are infinitely more reliable than unRAIDed disk drives, but rare extremely failure scenarios (usually those involving spilled coffee) can case loss of the entire array.

Monster is a moderately large Perforce shop, with ~500 users, 2.2+ million RCS files (not counting branch copies), 1.3 million changelists, 6+ years of Perforce history, a 29 gig checkpoint (~1.8 Gig compressed) on one Perforce server (plus some ~40 users on a much smaller second server instance for an acquired business division).

I hope this helps.

Cheers!

Tom

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com]On Behalf Of Lee Marzke
Sent: Friday, April 21, 2006 6:15 PM
To: Dan Bloch
Cc: perforce-user at perforce.com
Subject: Re: [p4] has anyone used a RAM-SAN?


Dan Bloch wrote:
> Thanks for the early returns ;-)  Some more information:
>
> We're running Linux RHAS 2.4.  Our metadata in our production system is on a
> 1+0 RAID local hard disk.  We have lots of memory and we're just running
> single-user benchmarks, so swapping is highly unlikely.
>
> Our current theory (still work in progress) is that a RAM-SAN is great for
> random access, but Perforce does a lot of large sequential disk accesses,
> which are already optimized for hard disks, so the bottleneck may be the I/O
> bus.
>
> Dan
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>   
Dan,

If your using FC/AL you might consider using a switched fabric,  and 
adding more
connection between your HBA and the RAM-SAN to increase bandwidth. 

See also:   http://en.wikipedia.org/wiki/Fibre_Channel

Lee Marzke




NOTICE:
This message may contain privileged or otherwise confidential information. If you are not the intended recipient, please immediately advise the sender by reply email and delete the message and any attachments without using, copying or disclosing the contents. (FE01)