Transaction logging = Poor Performance on Wintel?

I recently heard from a very senior Domino admin that in his experience with the Wintel platform and Domino that transaction logging actually hurts the performance of Domino on Wintel. I have worked with trasaction logging in the last three Domino shops I’ve worked at and never heard this before.

He stated that since I/O is the bottle-neck on Wintel that transaction logging actually worsened the performance of Domino on Windows. Does anyone have any factual statistics that can elaborate on the performance of Domino/Win 2003 w/transaction logging? I am very curious now that this has been brought to my attention.

We are gearing up for a major upgrade to our infrastructure and due to this input have abandoned transaction logging as an option for now. I would really like to know what the facts are in this situation.

Thanks!

Subject: Re: Transaction logging = Poor Performance on Wintel?

From the following TechNote:

Title: Notes/Domino Best Practices: Transaction Logging
Doc #: 7009309
URL: http://www.ibm.com/support/docview.wss?rs=899&uid=swg27009309

“Transaction logging improves performance by optimizing disk I/O. Domino R4 had “write-through” changes — a change to a database forced the server to attempt to write the change immediately to disk, regardless of how busy the server was at that point. Many operating systems would shield changes in the file cache, preventing the writes from going immediately to disk for performance reasons but introducing a window for data loss in the event of a server crash. In R5, it is no longer necessary to write immediately to disk since changes are in the transaction log. By batching I/O, the server can devote more cycles to applications, instead of being in kernel mode to perform disk I/O.”

Subject: I’m already familiar with that article. I need specifics

Not to be dismissive, but I’ve already read that document a long time ago. What I’m looking for are validated statistics that show an improvement in I/O on the Wintel platform. I have seen nothing that bears this out. I was very enthusiastic about transaction logging prior to talking to this consultant. What I want is something that can tangibly validate that there is a case to be made for this other than an IBM sales pitch.

Subject: test it on your hardware

That’s the only way you’ll know for sure.Use the serverload testing app and make sure you have enough spindles to put the transaction log on another drive…

Subject: The devil is in the details

I don’t think a blanket statement can be made either way in regards to transaction logging on Wintel.

How it will impact your environment will be largely dependant on the specs for the hardware in regards to your disk, and how it is carved up.

Subject: Agreed, but I am looking for empirical evidence

We are an applications only environment. The consultant I talked to indicated that in Domino 8.x a dirty database is a far cry from what was considered dirty after a crash in earlier versions of Domino. He said that crash recovery for a Domino server that is applications based would be acceptably quick without transaction logging.

Subject: Some answers

The best practices TN mentioned in a prior post in this thread links to many articles, some of which contain actual test data. You haven’t mentioned your disk configuration, so it’s important to remember that you need to isolate logging to a separate device at a minimum and a completely different disk subsystem (device and controller) if possible. Transaction logging is required for DAOS in 8.5, and you definitely want to look into that if you have I/O issues.

Subject: Wintel and I/O Issues Pls Read Below

Hello, This information should help. I have thousands of customers running Transactional Logging on Domino without Performance issues. Yes we do have other issues but if setup properly this should not be an issue.

MOST IMPORTANT INFO REGARDING PERFORMANCE:

Hardware considerations

Dedicated RAID1 Array ← Important or Perf Issues are expected.

It is absolutely essential to place the transaction log directory on a separate physical device devoted solely to transaction logging. Part of the performance improvement you will gain from transaction logging depends on having a separate disk, which allows fast writes to the transaction log files. Putting the transaction log on the same drive as other files — the operating system, the Domino executables, the Domino data, the OS pagefile, etc. — can result in a significant performance degradation even in comparison with an R4 server, since the server must read from and write to these files as well. This activity causes contention for the disk head — for example, the server might be reading information from a database while the logger tries to write a change to the transaction log. This can limit or remove the performance gains from transaction logging. Even in an environment with a storage area network (SAN), or an environment with a large physical drive logically addressed as multiple drives (for example, AS/400 or S/390 systems), it is still crucial that the logical transaction logging drive maps to a separate, dedicated physical drive. Each Domino server requires its own transaction log drive, including partitioned servers. The rule of thumb is “one log device per data directory, and one data directory per log device.”

Mirroring the log drive is also crucial, as losing a log drive or encountering a hardware failure risks losing log extents that may not have been backed up, and it also panics the server. RAID0 does not have a mirrored disk, making the log drive a single point of failure. RAID5 can offer mirroring, but has performance degradation due to extra write operations compared to a RAID1 log disk. Note that the media strategy for the transaction log disk is independent of the general server and Domino data strategy — a company could use RAID5 for the operating system and Domino data, but use a RAID1 disk array for the transaction log. Note also that in clustered environments, losing the log disk causes clients to fail over to a cluster member.

The disk size will depend on the logging style that you choose. With circular logging, the server uses a maximum of 4 GB of disk space. A typical mail server logs about 1 GB per day. You can determine how much data your organization is logging by using the transaction logging statistics provided by the Recovery Manager task (discussed later). Under circular logging, the recommendation is to use a 4 GB disk. Disk space is inexpensive and having the maximum space ensures that the server does not need to commit changes to disk under suboptimal conditions.

With archive logging, Domino uses all available space on the log disk (even if you set “Use all available space on log device” to No in the Server document). Archive logging depends on having a third-party backup utility to back up log extents and make them available for re-use. Domino re-uses extents when possible; if no re-usable extents are available, Domino creates a new extent. Therefore, disk sizing depends on how often an organization backs up its log extents. Typically, a 9 GB disk array will be more than sufficient to allow administrators to postpone backups until off hours. Backup products can allow you to specify that log extents should be backed up at a certain time (3:00 AM, for instance) unless the log disk is becoming full (for example, more than 70 percent full), in which case the utility should perform an immediate backup.


Other things to consider:

Notes.ini Parameters that should be added either with the Server Down or Using the Set Config Command:

These Parameters below can be added using the Set Config command on the Server Console to avoid Transactional Logging on Databases that should not be logged (Example SET CONFIG LOG_DISABLETXNLOGGING=1). The parameters will not take effect until the server is shutdown completely, the databases are removed and when the server is rebooted a new log.nsf, clubusy.nsf will be recreated and no longer be transactionally logged. All corresponding Technotes for these parameters are below the NSD Review: TN#1238392, TN#1251117, in versions prior to 8.5 we disabled Mail.box but that is no longer the case in 8.5

LOG_DisableTXNLogging=1 (Disabled TXN Logging on the Log.nsf)

Schedule_disabletxnlogging=1 (Disabled TXN Logging on the Clubusy.nsf)

You can also disable Transactional Logging for the following Databases on your server and the next time the server is restarted these databases will not be transactionally logged as it is unnecessary: names.nsf, statrep.nsf, statmail.nsf, webadmin.nsf, cldbdir.nsf. Note you do not have to recreate these database you just need to disable TXN Logging in the databases and the next time the server is restarted they will be excluded from the Logging.

To Turn Off Transactional Logging you can open the database and then go to File–>Database–>Properties–>Advanced tab

TECHNOTES:

################################################

Title: Notes/Domino Best Practices: Transaction Logging

Doc #: 7009309

URL: http://www.ibm.com/support/docview.wss?rs=899&uid=swg27009309

################################################

Title: Disabling transaction logging by default on log.nsf

Doc #: 1238392

URL: http://www.ibm.com/support/docview.wss?rs=899&uid=swg21238392

################################################

Title: Transaction Log grows and fills hard drive

Doc #: 1251117

URL: http://www.ibm.com/support/docview.wss?rs=899&uid=swg21251117

################################################