Re: msExchESEParamLogBuffers not set????

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??


.