Re: msExchESEParamLogBuffers not set????

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

In that case, no correlation between log stalls and spikes in disk access
time, increasing log buffers will likely help. When you see this scenario,
it's usually due to large attachments flowing through the system. Message
size limits would also help in this case.


"rhalljr" <spam2005account@xxxxxxxxx> wrote in message
news:3lhig.33100$8G3.24389@xxxxxxxxxxxxxxxxxxxxxxx
rhalljr wrote:
John Fullbright [MVP] wrote:
That was step 1.

Step 2 is collect physical disk - sec/write and Database - log record
stall per second at a small interval ( a couple of seconds ) and compare
the two. Do spikes in log stalls correlate to spikes in disk times for
the log drive?


"rhalljr" <spam2005account@xxxxxxxxx> wrote in message
news:bAfig.33089$8G3.26880@xxxxxxxxxxxxxxxxxxxxxxx
John Fullbright [MVP] wrote:
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?

according to the exchange Performance Troubleshooting Analyzer, i am
Getting a spike in log record stalls greater than 100 per second.


it appears that i am getting a pretty high level of Processor load, and
log stall. Disk write sec doesnt appear bad.
wait... i had the colors mixed up in Perfmon. The log stall wasnt bad, but
the disk writes/sec were pretty high.


.

Quantcast