February 17 2010 Wednesday
The very un-scientific look at transaction logging on Domino - part 2 - a real world server
In my earlier post, A very un-scientific look at transaction logging in Domino I'd speculated about the Database.RM.Logger.IO Domino statistics.
As I'd mentioned right at the bottom of that post (and Richard also did in a comment) IO.Avg.Write.Time is probably more likely the statistic you need for production and not necessarily IO.Max.Write.Time. We'll look at both statistics for a server that has few users (<100) but huge amounts of email traffic. This is a production mail and apps server where we will move the transaction logs from the c: drive to a discrete disk. Let's see what we get....
The server in question is Domino 8.5.1 running on Windows 2003 32 bit server. It has a lot of traffic. For this exercise we will move the transaction logs from the c: drive which houses apps, OS and page file drive and the TX logs (the way the original server was configured) and move them to a discrete SATA disk. This new disk is a straight 500GB SATA2 7200 RPM drive . The original OS, apps and page file drive was a 3 disk RAID 5 array using SATA drives on a Dell PERC 5 controller. Domino data is situated on a separate 5 disk RAID 5 array also connected to the PERC.
Before the TX Log move, we have our stats. The server has been running about 6 days at this point.
Post TX Log move, after 6 days we have the following:
As you can see the difference is nothing short of staggering. The IO.Max.Write.Time is reduced by 99% and the IO.Avg.Write.Time went down by 77 orders of magnitude!
I can only imagine what a transaction log write that takes 8.2 seconds will do to Domino performance.If you have any doubt that the recommendation to move Domino transactions logs to discrete drive(s) is hog wash, then I beg to differ. If you have a very busy server and/or lots of users get the fastest drives possible (currently solid state drives or SSDs). There was some talk a while ago on Stephan Wissel's blog where SSD's we accused of being the latest panacea for poor Domino performance and that they are no faster in sequential writes than traditional (mechanical) drives. While they maybe a panacea (but you want a fast server, right?) they are hands down faster than traditional drives. If you are seeing high IO.Avg.Write.Time values then it could be well worth the investment. Regardless of where you sit on the SSD debate, put transaction logs on a discrete drive or array, period!
I''ll take a second to point out why I believe the IO.Number.Writes is so low on the second screen grab. This is not due to moving the TX Logs, but because this customer moved from Symantec Mail Security for Domino Anti-Spam to Lotus Protector for Mail Security. This removed some 4,000 messages per day from the Domino system (mail.box, etc) as Protector blocked them. I'll keep track of this over the next few weeks and when/if we get to a comparable IO.Number.Writes I will post again (quick math says 10 weeks....on a Windows server, hum). I have a feeling the IO.Avg.Write.Time and the IO.Max.Write.Time will not be adversely affected.
As I'd mentioned right at the bottom of that post (and Richard also did in a comment) IO.Avg.Write.Time is probably more likely the statistic you need for production and not necessarily IO.Max.Write.Time. We'll look at both statistics for a server that has few users (<100) but huge amounts of email traffic. This is a production mail and apps server where we will move the transaction logs from the c: drive to a discrete disk. Let's see what we get....
The server in question is Domino 8.5.1 running on Windows 2003 32 bit server. It has a lot of traffic. For this exercise we will move the transaction logs from the c: drive which houses apps, OS and page file drive and the TX logs (the way the original server was configured) and move them to a discrete SATA disk. This new disk is a straight 500GB SATA2 7200 RPM drive . The original OS, apps and page file drive was a 3 disk RAID 5 array using SATA drives on a Dell PERC 5 controller. Domino data is situated on a separate 5 disk RAID 5 array also connected to the PERC.
Before the TX Log move, we have our stats. The server has been running about 6 days at this point.
Post TX Log move, after 6 days we have the following:
As you can see the difference is nothing short of staggering. The IO.Max.Write.Time is reduced by 99% and the IO.Avg.Write.Time went down by 77 orders of magnitude!
I can only imagine what a transaction log write that takes 8.2 seconds will do to Domino performance.If you have any doubt that the recommendation to move Domino transactions logs to discrete drive(s) is hog wash, then I beg to differ. If you have a very busy server and/or lots of users get the fastest drives possible (currently solid state drives or SSDs). There was some talk a while ago on Stephan Wissel's blog where SSD's we accused of being the latest panacea for poor Domino performance and that they are no faster in sequential writes than traditional (mechanical) drives. While they maybe a panacea (but you want a fast server, right?) they are hands down faster than traditional drives. If you are seeing high IO.Avg.Write.Time values then it could be well worth the investment. Regardless of where you sit on the SSD debate, put transaction logs on a discrete drive or array, period!
I''ll take a second to point out why I believe the IO.Number.Writes is so low on the second screen grab. This is not due to moving the TX Logs, but because this customer moved from Symantec Mail Security for Domino Anti-Spam to Lotus Protector for Mail Security. This removed some 4,000 messages per day from the Domino system (mail.box, etc) as Protector blocked them. I'll keep track of this over the next few weeks and when/if we get to a comparable IO.Number.Writes I will post again (quick math says 10 weeks....on a Windows server, hum). I have a feeling the IO.Avg.Write.Time and the IO.Max.Write.Time will not be adversely affected.
Darren Duke
|
February 17 2010 10:20:24 AM
|
domino transaction logging
|
