I came across this with a client about a year back now, and thought the lack of doc would have been resolved by now. To my surprise this came up in a series of threads (again) internally and it appears that we have not yet discussed this in our documentation or blogs.
I'll look around to see if I can find a link to what this is actually doing - but the short answer is that the log buffer is the first locations transactions are written too (in memory) and thus any slow down (or stall) causes an immediate performance bottle neck.
Log Record Stalls/Sec recommendations are quite simple: keep as low as possible (zero is a great number) and if you see a value about 10 look to do some sort of remidiation of the situation. With Ex2k and Ex2k3 the first recommendation we made was to adjust the log buffer size and then see what this value looked like. But when we see this value in Ex2k7 being high what value do we adjust it to?
The answer is simple but needs to be explained (IMHO) a bit.
In Ex2k3 the ExBPA would recommend setting the msexchESEParamLogBuffers paramiter to 9000 (http://technet.microsoft.com/en-us/library/aa998473(EXCHG.65).aspx) the short answer to why we say this is as follows (please understand this is to the best of my knowledge and i'd be happy if one of the Exchange Escalation Engineers corrected me):
In Exchange 2000 (all versions), the default number of buffers is 84 - that is to say default value when the property in the AD shows <Not Set> is 84. The JET engine (Exchange Engine if you will) normalizes this to 128, so you end up with 128 total buffers /SG. Over the years our PSS engineers found that transaction log replace could be greatly speeded up by increasing this bugger - see some good comes from DR situations :) As an added benfiti this larger buffer size also help reduce log buffer stalls the recommendation was to bump the value to 9000. The problem with running with this much larger value in the Windows 2000/Exchange 2000 days was a large increase in virtual memory consumption and fragmentation. Thus to balance the need to increase transaction log replay / log bugger stalls and increased VM issues the value of 512 was decided on vs the 9000.
In Exchange 2003 (all versions), the default number of buffers is 500 - that is again to say the default value when the property in the AD shows <Not Set>. Unfortunately, JET normalization wasn't taken into consideration when the store code was changed, so you actually end up with 384 buffers. So, is why some of the original documentation on Exchange 2003 says that it should be set manually to 512 (to stop this resetting to a lower value and forcing it to 512).
Out product group started to do some serious test casing with this value around this time and found that scale-up servers generally benefit from an increase in log buffers, and in the much more common higher density configurations we find today, increasing log buffers is pretty much a must. The value of 9000 was determined to be again the best trade off value between VM and performance. As a trivia pursuit question: the JET engine normalizes 9000 down to 8960 - due to the fact each buffer is one disk sector (512 bytes) in size and JET engine normalizes on 64 KB boundaries (do the math if you wish).
Now after that very long explanation we get to what value Exchange 2007 needs.
The answer: None.
This parameter is no longer read and the log bugger size has been set to nearly 1 MB (again not exactly due to the math). With transaction log sizes being 1 MB in size (for MB servers) this allows for a very nice buffer to log file ratio.
If you are seeing log buffer stalls in Ex2k7 you should move the transaction logs to a faster disk and revisit the perfmon capture to see the effects.
I'll look around to see if I can find a link to what this is actaully doing - but the short answer is that the log buffer is the first locations transactions are writen too (in memeory) and thus any slow down (or stall) causes an imidiate perfomrance bottle kneck.
rs
