Re: msExchESEParamLogBuffers not set????

John Fullbright [MVP] wrote:
The default is 84. The max recommended for E2K3 SP1 or 2 is 9000. The recommended max is different depending on the version of exchange.



One common source of the "requesting data" dialog box is a log stall. A log stall happens when log buffers fill to the high water mark. Client IO is quiesced and logs are flused to disk until the low water mark is reached. Will changing the number of buffers have any impact? It depends. If log stalls are an issue, and there is no correlation to slow response times on the log drive, then increasing log buffers might help. If there is a correlation to slow response times on the log drive, it will probably make things worse. The root cause in that case is slow disk.

Collect Database - log record stalls/sec and Physical disk - avg disk sec/write (for the log drive(s)) at a very frequent interval (a few seconds) and look for correlations between spikes in the two counters. "Average disk write times over 20 ms (.020) or peaks over 50ms lasting more than a few seconds" are considered signs of poor disk performance according to "Optimizing Storage for Exchange Server 2003".

Not too long ago, it was considered a bad thing if log stalls were above 0. The guidance has changed to above an average of 10 or spickes greater than 100. I suspect this is for the same reason that jetstress.doc hedges the 20ms response time and uses Database page fault stalls/sec in cases where synchronous replication is used. With synchronous replication a write isn't complete until the primary and replicated storage both send a complete. Due to the speed of light and distance, it's awfully hard for geographically dispersed synchronous replication to make that 20ms time.

Exchange uses jet, a btree+ database. Everything resides in pages. A certain number of those pages are mapped into memory at any given time and is controlled by msExchESEParamCacheSizeMax. If a page that is requested is not in cache, it's retrieved from disk. That's a page fault. When all the pages in cache are locked, and a page fault occurs, that's a page fault stall. As you can imagine, that's a really bad thing and a sign of a serious disk bottleneck. Database page fault stalls/sec should always be 0.





"rhalljr" <spam2005account@xxxxxxxxx> wrote in message news:1dXhg.14134$W97.6899@xxxxxxxxxxxxxxxxxxxxxxx
Is this right? It appears that this setting did not have anything set?

i changed it to 9000 like everything else says.

Do you think this could help get rid of the RPC "nag" screen that i am getting??


I ran HD tach on my drives, and they seem to be pretty responsive. The server is a Dell 2800 Dual 3.8GHZ Xeon, 8GB Ram, with 4 300GB Ultra 320 configured in Raid 10. So i think the Disks are plenty fast enough. I tend to be leaning more towards the Log Buffers as being the culprit.

We have less than 100 Mailboxes, and around 73 users, so this should be more than enough power for what we are using

Any advice on the Log buffers?
.