MS SQL Server - Waiting for type 0x4, current count 0x808, current owning EC 0x00000000.

Author

Waiting for type 0x4, current count 0x808, current owning EC 0x00000000.

2005-06-02, 8:23 pm

Hi,
We are running SQl server 2000 SP3a and AWE enabled and I believe
PAE is enabled too. The server has 7GB of memory. 20GB of Paging space
and 28GB of Virtual Memory. It's a 4 cpu 2.9GHZ.

We had a whole bunch of errors in SQl server logs about waiting for a
latch, and then eventually the system just stopped responding and we
had to reboot.

Initially it started of with these messages.

2005-06-02 09:11:59.25 spid81 WARNING: Failed to reserve contiguous
memory of Size= 294322176.
2005-06-02 09:11:59.28 spid81 Buffer Distribution: Stolen=16931
Free=2253 Procedures=29238
Inram=0 Dirty=42000 Kept=0
I/O=0, Latched=113, Other=632921
2005-06-02 09:11:59.28 spid81 Buffer Counts: Commited=723456
Target=723456 Hashed=675034
InternalReservation=
406 ExternalReservation=
3312 Min Free=500
2005-06-02 09:11:59.28 spid81 Procedure Cache: TotalProcs=21708
TotalPages=29238 InUsePages=13216
2005-06-02 09:11:59.28 spid81 Dynamic Memory Manager: Stolen=41337
OS Reserved=2624
OS Committed=2598
OS In Use=2573
Query Plan=29209 Optimizer=0
General=5303
Utilities=657 Connection=211
2005-06-02 09:11:59.28 spid81 Global Memory Objects: Resource=2719
Locks=8429
SQLCache=845 Replication=52
LockBytes=2 ServerGlobal=48
Xact=229
2005-06-02 09:11:59.28 spid81 Query Memory Manager: Grants=1
Waiting=0 Maximum=230985 Available=222841

Then we had the latch messages.

2005-06-02 09:18:36.84 spid81 WARNING: EC 64d7b598, 0 waited 300
sec. on latch a1315c. Not a BUF latch.
2005-06-02 09:18:36.84 spid81 Waiting for type 0x4, current count
0x808, current owning EC 0x00000000.
2005-06-02 09:18:36.91 spid55 WARNING: EC bf865598, 0 waited 300
sec. on latch a1315c. Not a BUF latch.
2005-06-02 09:18:36.91 spid55 Waiting for type 0x2, current count
0x808, current owning EC 0x00000000.
2005-06-02 09:18:37.93 spid86 WARNING: EC bfd11538, 0 waited 300
sec. on latch a1315c. Not a BUF latch.
2005-06-02 09:18:37.93 spid86 Waiting for type 0x2, current count
0x808, current owning EC 0x00000000.

Eventually the wait time increased to 600,900 and even 1800 secs.

We monitored the CPU usage and memory, and found that it was only using
25-30% and the memory was 5.8GB.

Could some one please help me interpret these messages.

I read a whole bunch of MS articles, but couldn't figure out what latch
was it waiting on, and why?

Thanks for your help.
GG

Mike Epprecht \(SQL MVP\)

2005-06-02, 8:23 pm

Hi

There are quite a few fixes post SP3 for this issue if you look at:

http://support.microsoft.com/search...ype=ALL&Titles=
false&numDays=&MaxResults=25&srchstep=1&InCC_hdn=true& querySource=gASr_Que
ry

--
--------------------------------
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland

IM: mike@epprecht.net

MVP Program: http://www.microsoft.com/mvp

Blog: http://www.msmvps.com/epprecht/

"GG" <gdabbara@gmail.com> wrote in message
news:1117741340.742329.20240@f14g2000cwb.googlegroups.com...
> Hi,
> We are running SQl server 2000 SP3a and AWE enabled and I believe
> PAE is enabled too. The server has 7GB of memory. 20GB of Paging space
> and 28GB of Virtual Memory. It's a 4 cpu 2.9GHZ.
>
> We had a whole bunch of errors in SQl server logs about waiting for a
> latch, and then eventually the system just stopped responding and we
> had to reboot.
>
> Initially it started of with these messages.
>
> 2005-06-02 09:11:59.25 spid81 WARNING: Failed to reserve contiguous
> memory of Size= 294322176.
> 2005-06-02 09:11:59.28 spid81 Buffer Distribution: Stolen=16931
> Free=2253 Procedures=29238
> Inram=0 Dirty=42000 Kept=0
> I/O=0, Latched=113, Other=632921
> 2005-06-02 09:11:59.28 spid81 Buffer Counts: Commited=723456
> Target=723456 Hashed=675034
> InternalReservation=
406 ExternalReservation=
3312 Min Free=500
> 2005-06-02 09:11:59.28 spid81 Procedure Cache: TotalProcs=21708
> TotalPages=29238 InUsePages=13216
> 2005-06-02 09:11:59.28 spid81 Dynamic Memory Manager: Stolen=41337
> OS Reserved=2624
> OS Committed=2598
> OS In Use=2573
> Query Plan=29209 Optimizer=0
> General=5303
> Utilities=657 Connection=211
> 2005-06-02 09:11:59.28 spid81 Global Memory Objects: Resource=2719
> Locks=8429
> SQLCache=845 Replication=52
> LockBytes=2 ServerGlobal=48
> Xact=229
> 2005-06-02 09:11:59.28 spid81 Query Memory Manager: Grants=1
> Waiting=0 Maximum=230985 Available=222841
>
>
> Then we had the latch messages.
>
> 2005-06-02 09:18:36.84 spid81 WARNING: EC 64d7b598, 0 waited 300
> sec. on latch a1315c. Not a BUF latch.
> 2005-06-02 09:18:36.84 spid81 Waiting for type 0x4, current count
> 0x808, current owning EC 0x00000000.
> 2005-06-02 09:18:36.91 spid55 WARNING: EC bf865598, 0 waited 300
> sec. on latch a1315c. Not a BUF latch.
> 2005-06-02 09:18:36.91 spid55 Waiting for type 0x2, current count
> 0x808, current owning EC 0x00000000.
> 2005-06-02 09:18:37.93 spid86 WARNING: EC bfd11538, 0 waited 300
> sec. on latch a1315c. Not a BUF latch.
> 2005-06-02 09:18:37.93 spid86 Waiting for type 0x2, current count
> 0x808, current owning EC 0x00000000.
>
> Eventually the wait time increased to 600,900 and even 1800 secs.
>
> We monitored the CPU usage and memory, and found that it was only using
> 25-30% and the memory was 5.8GB.
>
> Could some one please help me interpret these messages.
>
> I read a whole bunch of MS articles, but couldn't figure out what latch
> was it waiting on, and why?
>
> Thanks for your help.
> GG
>

Anthony Thomas

2005-06-02, 8:23 pm

The problem is that, as Mike said, there have been several issues with the
release of lower bound, but external memory reservations. However, even
with these fixes, you may still have the problem, especially with AWE.

The problem is that all active memory must live in the 4 GB virtual memory
limitation of 32-bit architectures. The /PAE switch tells the OS to use a
36-bit address map instead of the default 32-bit, which will allow an
address space of up to 64 GB. Again, however, only 4 GB can be active at
one time; thus, Address WINDOWing Extension. This shifts a 4 GB Window
through the addressable 64 GB region whenever PAE is enabled, but only
applications that make use of these extensions can benefit from it, like SQL
Server.

Here's the problem, when you enable AWE, you switch SQL Server from using
Dynamic Memory Management to Static Address Windowing mapping. However, all
external reservations must still be made from the lower 4 GB of memory, of
which there may be little and now that SQL Server is no longer in Dynamic
Managment mode, it will not give it up.

What the error logs are telling you is that the lower 4 GB, and, more
likely, the 2 GB User Mode space, is consumed and/or severely fragmented.

Three possible workarounds:

1. Enable the /3GB boot.ini switch. This will shift the Kernel Mode/User
Mode default partition from a 2 GB/2 GB mix to a 1 GB/3 GB mix for the lower
4 GB of addressable virtual memory and will give you an additional 1 GB to
use and/or fragment before causing problems.

2. When using AWE, you need to force some of the usage out of the lower 4 GB
and more into the higher than 4 GB. Set SQL Server to only use 6 to 6.5 GB
of that 7 GB available. Then, retain some of the lower space for external
allocations by using the -g Start Up parameter. A value of 384 to 512
should be sufficient to start with.

3. At the next maintenance opportunity after receiving errors like this,
reboot the server. This will flush out the memory and the memory
fragmentation. You will have to do this periodically.

As an alternative, consider migrating to 64-bit SQL Server, which can use
all of the 7 GB you have without AWE thus remaining in Dynamic Memory
Management mode.

Hope this helps.

Sincerely,

Anthony Thomas

--

"Mike Epprecht (SQL MVP)" <mike@epprecht.net> wrote in message
news:un1MYU7ZFHA.612@TK2MSFTNGP12.phx.gbl...
Hi

There are quite a few fixes post SP3 for this issue if you look at:

http://support.microsoft.com/search...ype=ALL&Titles=
false&numDays=&MaxResults=25&srchstep=1&InCC_hdn=true& querySource=gASr_Que
ry

--
--------------------------------
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland

IM: mike@epprecht.net

MVP Program: http://www.microsoft.com/mvp

Blog: http://www.msmvps.com/epprecht/

"GG" <gdabbara@gmail.com> wrote in message
news:1117741340.742329.20240@f14g2000cwb.googlegroups.com...
> Hi,
> We are running SQl server 2000 SP3a and AWE enabled and I believe
> PAE is enabled too. The server has 7GB of memory. 20GB of Paging space
> and 28GB of Virtual Memory. It's a 4 cpu 2.9GHZ.
>
> We had a whole bunch of errors in SQl server logs about waiting for a
> latch, and then eventually the system just stopped responding and we
> had to reboot.
>
> Initially it started of with these messages.
>
> 2005-06-02 09:11:59.25 spid81 WARNING: Failed to reserve contiguous
> memory of Size= 294322176.
> 2005-06-02 09:11:59.28 spid81 Buffer Distribution: Stolen=16931
> Free=2253 Procedures=29238
> Inram=0 Dirty=42000 Kept=0
> I/O=0, Latched=113, Other=632921
> 2005-06-02 09:11:59.28 spid81 Buffer Counts: Commited=723456
> Target=723456 Hashed=675034
> InternalReservation=
406 ExternalReservation=
3312 Min Free=500
> 2005-06-02 09:11:59.28 spid81 Procedure Cache: TotalProcs=21708
> TotalPages=29238 InUsePages=13216
> 2005-06-02 09:11:59.28 spid81 Dynamic Memory Manager: Stolen=41337
> OS Reserved=2624
> OS Committed=2598
> OS In Use=2573
> Query Plan=29209 Optimizer=0
> General=5303
> Utilities=657 Connection=211
> 2005-06-02 09:11:59.28 spid81 Global Memory Objects: Resource=2719
> Locks=8429
> SQLCache=845 Replication=52
> LockBytes=2 ServerGlobal=48
> Xact=229
> 2005-06-02 09:11:59.28 spid81 Query Memory Manager: Grants=1
> Waiting=0 Maximum=230985 Available=222841
>
>
> Then we had the latch messages.
>
> 2005-06-02 09:18:36.84 spid81 WARNING: EC 64d7b598, 0 waited 300
> sec. on latch a1315c. Not a BUF latch.
> 2005-06-02 09:18:36.84 spid81 Waiting for type 0x4, current count
> 0x808, current owning EC 0x00000000.
> 2005-06-02 09:18:36.91 spid55 WARNING: EC bf865598, 0 waited 300
> sec. on latch a1315c. Not a BUF latch.
> 2005-06-02 09:18:36.91 spid55 Waiting for type 0x2, current count
> 0x808, current owning EC 0x00000000.
> 2005-06-02 09:18:37.93 spid86 WARNING: EC bfd11538, 0 waited 300
> sec. on latch a1315c. Not a BUF latch.
> 2005-06-02 09:18:37.93 spid86 Waiting for type 0x2, current count
> 0x808, current owning EC 0x00000000.
>
> Eventually the wait time increased to 600,900 and even 1800 secs.
>
> We monitored the CPU usage and memory, and found that it was only using
> 25-30% and the memory was 5.8GB.
>
> Could some one please help me interpret these messages.
>
> I read a whole bunch of MS articles, but couldn't figure out what latch
> was it waiting on, and why?
>
> Thanks for your help.
> GG
>

Sponsored Links