Re: msExchESEParamLogBuffers not set????

Log buffers address log stalls in some sitations (no disk bottleneck and
large attachments flowing through the system). To determine if increasing
them will help, first verify that you have a promlem with log stalls. There
are many other potential causes of the RPC dialog, log stalls just happen to
be commom.


"rhalljr" <spam2005account@xxxxxxxxx> wrote in message
news:d4Zhg.14154$W97.2566@xxxxxxxxxxxxxxxxxxxxxxx
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?


.