Please, take a look at "Inside SQL Server 2000's Memory Management Facilities" by Ken Henderson:
http://msdn.microsoft.com/library/de...v_01262004.asp
"... None of the tools you typically use to inspect application memory use (Task Manager, Perfmon/Sysmon, etc.) show the amount of AWE memory used by individual processes. There's no indication of the amount of AWE memory used by each process, nor is this
memory included in the working set size reported for a given process ..."
Thanks,
-Ivan
--Original Message--
From: james
Posted At: Tuesday, February 28, 2006 6:52 AM
Posted To: microsoft.public.sqlserver.server
Conversation: MemToLeave area! How to monitor?
Subject: MemToLeave area! How to monitor?
Gurus,
Occasionally I get the error of "WARNING: Failed to reserve contiguous memory of Size= 65536."
What is the unit for this size, is it bytes or KB? Additionally,
I have set up 511 MB for MemToLeave area by adding -g384 for Sql2k SP3a on AWE enabled system. I have total of 16 GB of RAM, of which 14 GB is set up maximum for Sql server.
If I look at Perfmon counter of Process->Private bytes for sql server process it gives me 224 MB.
If I look at sqlserver.exe process on task manager it gives me 215MB.
If I look at DBCC memorystatus, OS in use, it gives me 12 MB.
I would like to know, How can I calculate exactly how much memory is being assigned and how much in use from MemToLeave area by looking at above mentioned counters or any other perfmon or dbcc counters?
I really appreciate any input on this matter.
Thanks Ivan. I had already checked that article and also few other google
search but didn't get the answer.
<ivanpe@.online.microsoft.com> wrote in message
news:OenNh9IPGHA.3840@.TK2MSFTNGP14.phx.gbl...
> Please, take a look at "Inside SQL Server 2000's Memory Management
> Facilities" by Ken Henderson:
> http://msdn.microsoft.com/library/de...v_01262004.asp
> "... None of the tools you typically use to inspect application memory use
> (Task Manager, Perfmon/Sysmon, etc.) show the amount of AWE memory used by
> individual processes. There's no indication of the amount of AWE memory
> used by each process, nor is this memory included in the working set size
> reported for a given process ..."
> Thanks,
> -Ivan
> --Original Message--
> From: james
> Posted At: Tuesday, February 28, 2006 6:52 AM
> Posted To: microsoft.public.sqlserver.server
> Conversation: MemToLeave area! How to monitor?
> Subject: MemToLeave area! How to monitor?
>
> Gurus,
> Occasionally I get the error of "WARNING: Failed to reserve contiguous
> memory of Size= 65536."
> What is the unit for this size, is it bytes or KB? Additionally,
> I have set up 511 MB for MemToLeave area by adding -g384 for Sql2k SP3a on
> AWE enabled system. I have total of 16 GB of RAM, of which 14 GB is set up
> maximum for Sql server.
> If I look at Perfmon counter of Process->Private bytes for sql server
> process it gives me 224 MB.
> If I look at sqlserver.exe process on task manager it gives me 215MB.
> If I look at DBCC memorystatus, OS in use, it gives me 12 MB.
> I would like to know, How can I calculate exactly how much memory is being
> assigned and how much in use from MemToLeave area by looking at above
> mentioned counters or any other perfmon or dbcc counters?
> I really appreciate any input on this matter.
|||James,
The unit of measure in the message you list is bytes, not KB. Basically,
the memory mgr is failing to reserve 64KB of memory.
The numbers you report from the various monitoring tools don't sound
surprising -- they all measure different things. For example,
Process:Private Bytes is a measure of _committed_ virtual memory, not
reserved. -G controls the region set aside for MTL, not committed or
reserved -- free. That virtual memory is reserved and committed as needed
by the various memory consumers running inside the SQL Server process.
Also, on SS2K, AWE can't be used for anything except caching data and index
pages. Regular MTL allocations never come from AWE.
Keep in mind that the MTL region is really not a region at all but just
refers to the memory left over once the BPool takes what it needs. It's the
unused virtual memory in the process's virtual address space. -G can grow
or shrink this area, but it basically only amounts to unused memory within
the process.
Allocations by external consumers (COM objects, xprocs (usually), OLEDB
providers, etc.) come from MTL. Also, allocations by the server itself that
are >8KB are serviced from MTL rather than the BPool. This just means that,
at some level, they call VirtualAlloc to allocate VM directly from Windows
rather than using pages already allocated to the BPool.
Accompanying the error message you list should be the equivalent of DBCC
MEMORYSTATUS output. This is more relevant than running the command
yourself because it's taken at the exact moment the error occurred. If I
were you, I'd have a look at the various buckets listed in that report to
see if any of them seem high. Keep in mind that many of them are page
counts, not byte counts, so you need to multiply them by 8KB to get the
exact byte count in use.
Also keep in mind that this error can be caused by extreme fragmentation as
well as over-allocation of memory. IOW, you could have well more than 64KB
available within the process, but no single contiguous block of that size or
larger.
If, after you've worked through the above, you still can't figure out why
the reservation is failing, you might want to contact PSS to help you
troubleshoot it further. They deal with these all the time and should be
able to get you fixed up in no time.
HTH,
-kh
"james" <kush@.brandes.com> wrote in message
news:%23hTPNHLPGHA.720@.TK2MSFTNGP14.phx.gbl...
> Thanks Ivan. I had already checked that article and also few other google
> search but didn't get the answer.
> <ivanpe@.online.microsoft.com> wrote in message
> news:OenNh9IPGHA.3840@.TK2MSFTNGP14.phx.gbl...
>
Showing posts with label area. Show all posts
Showing posts with label area. Show all posts
Wednesday, March 21, 2012
MemToLeave area! How to monitor?
Please, take a look at "Inside SQL Server 2000's Memory Management Facilitie
s" by Ken Henderson:
http://msdn.microsoft.com/library/d...ev_01262004.asp
"... None of the tools you typically use to inspect application memory use (
Task Manager, Perfmon/Sysmon, etc.) show the amount of AWE memory used by in
dividual processes. There's no indication of the amount of AWE memory used b
y each process, nor is this
memory included in the working set size reported for a given process ..."
Thanks,
-Ivan
--Original Message--
From: james
Posted At: Tuesday, February 28, 2006 6:52 AM
Posted To: microsoft.public.sqlserver.server
Conversation: MemToLeave area! How to monitor?
Subject: MemToLeave area! How to monitor?
Gurus,
Occasionally I get the error of "WARNING: Failed to reserve contiguous memo
ry of Size= 65536."
What is the unit for this size, is it bytes or KB? Additionally,
I have set up 511 MB for MemToLeave area by adding -g384 for Sql2k SP3a on A
WE enabled system. I have total of 16 GB of RAM, of which 14 GB is set up ma
ximum for Sql server.
If I look at Perfmon counter of Process->Private bytes for sql server proces
s it gives me 224 MB.
If I look at sqlserver.exe process on task manager it gives me 215MB.
If I look at DBCC memorystatus, OS in use, it gives me 12 MB.
I would like to know, How can I calculate exactly how much memory is being a
ssigned and how much in use from MemToLeave area by looking at above mention
ed counters or any other perfmon or dbcc counters?
I really appreciate any input on this matter.Thanks Ivan. I had already checked that article and also few other google
search but didn't get the answer.
<ivanpe@.online.microsoft.com> wrote in message
news:OenNh9IPGHA.3840@.TK2MSFTNGP14.phx.gbl...
> Please, take a look at "Inside SQL Server 2000's Memory Management
> Facilities" by Ken Henderson:
> http://msdn.microsoft.com/library/d...ev_01262004.asp
> "... None of the tools you typically use to inspect application memory use
> (Task Manager, Perfmon/Sysmon, etc.) show the amount of AWE memory used by
> individual processes. There's no indication of the amount of AWE memory
> used by each process, nor is this memory included in the working set size
> reported for a given process ..."
> Thanks,
> -Ivan
> --Original Message--
> From: james
> Posted At: Tuesday, February 28, 2006 6:52 AM
> Posted To: microsoft.public.sqlserver.server
> Conversation: MemToLeave area! How to monitor?
> Subject: MemToLeave area! How to monitor?
>
> Gurus,
> Occasionally I get the error of "WARNING: Failed to reserve contiguous
> memory of Size= 65536."
> What is the unit for this size, is it bytes or KB? Additionally,
> I have set up 511 MB for MemToLeave area by adding -g384 for Sql2k SP3a on
> AWE enabled system. I have total of 16 GB of RAM, of which 14 GB is set up
> maximum for Sql server.
> If I look at Perfmon counter of Process->Private bytes for sql server
> process it gives me 224 MB.
> If I look at sqlserver.exe process on task manager it gives me 215MB.
> If I look at DBCC memorystatus, OS in use, it gives me 12 MB.
> I would like to know, How can I calculate exactly how much memory is being
> assigned and how much in use from MemToLeave area by looking at above
> mentioned counters or any other perfmon or dbcc counters?
> I really appreciate any input on this matter.|||James,
The unit of measure in the message you list is bytes, not KB. Basically,
the memory mgr is failing to reserve 64KB of memory.
The numbers you report from the various monitoring tools don't sound
surprising -- they all measure different things. For example,
Process:Private Bytes is a measure of _committed_ virtual memory, not
reserved. -G controls the region set aside for MTL, not committed or
reserved -- free. That virtual memory is reserved and committed as needed
by the various memory consumers running inside the SQL Server process.
Also, on SS2K, AWE can't be used for anything except caching data and index
pages. Regular MTL allocations never come from AWE.
Keep in mind that the MTL region is really not a region at all but just
refers to the memory left over once the BPool takes what it needs. It's the
unused virtual memory in the process's virtual address space. -G can grow
or shrink this area, but it basically only amounts to unused memory within
the process.
Allocations by external consumers (COM objects, xprocs (usually), OLEDB
providers, etc.) come from MTL. Also, allocations by the server itself that
are >8KB are serviced from MTL rather than the BPool. This just means that,
at some level, they call VirtualAlloc to allocate VM directly from Windows
rather than using pages already allocated to the BPool.
Accompanying the error message you list should be the equivalent of DBCC
MEMORYSTATUS output. This is more relevant than running the command
yourself because it's taken at the exact moment the error occurred. If I
were you, I'd have a look at the various buckets listed in that report to
see if any of them seem high. Keep in mind that many of them are page
counts, not byte counts, so you need to multiply them by 8KB to get the
exact byte count in use.
Also keep in mind that this error can be caused by extreme fragmentation as
well as over-allocation of memory. IOW, you could have well more than 64KB
available within the process, but no single contiguous block of that size or
larger.
If, after you've worked through the above, you still can't figure out why
the reservation is failing, you might want to contact PSS to help you
troubleshoot it further. They deal with these all the time and should be
able to get you fixed up in no time.
HTH,
-kh
"james" <kush@.brandes.com> wrote in message
news:%23hTPNHLPGHA.720@.TK2MSFTNGP14.phx.gbl...
> Thanks Ivan. I had already checked that article and also few other google
> search but didn't get the answer.
> <ivanpe@.online.microsoft.com> wrote in message
> news:OenNh9IPGHA.3840@.TK2MSFTNGP14.phx.gbl...
>
s" by Ken Henderson:
http://msdn.microsoft.com/library/d...ev_01262004.asp
"... None of the tools you typically use to inspect application memory use (
Task Manager, Perfmon/Sysmon, etc.) show the amount of AWE memory used by in
dividual processes. There's no indication of the amount of AWE memory used b
y each process, nor is this
memory included in the working set size reported for a given process ..."
Thanks,
-Ivan
--Original Message--
From: james
Posted At: Tuesday, February 28, 2006 6:52 AM
Posted To: microsoft.public.sqlserver.server
Conversation: MemToLeave area! How to monitor?
Subject: MemToLeave area! How to monitor?
Gurus,
Occasionally I get the error of "WARNING: Failed to reserve contiguous memo
ry of Size= 65536."
What is the unit for this size, is it bytes or KB? Additionally,
I have set up 511 MB for MemToLeave area by adding -g384 for Sql2k SP3a on A
WE enabled system. I have total of 16 GB of RAM, of which 14 GB is set up ma
ximum for Sql server.
If I look at Perfmon counter of Process->Private bytes for sql server proces
s it gives me 224 MB.
If I look at sqlserver.exe process on task manager it gives me 215MB.
If I look at DBCC memorystatus, OS in use, it gives me 12 MB.
I would like to know, How can I calculate exactly how much memory is being a
ssigned and how much in use from MemToLeave area by looking at above mention
ed counters or any other perfmon or dbcc counters?
I really appreciate any input on this matter.Thanks Ivan. I had already checked that article and also few other google
search but didn't get the answer.
<ivanpe@.online.microsoft.com> wrote in message
news:OenNh9IPGHA.3840@.TK2MSFTNGP14.phx.gbl...
> Please, take a look at "Inside SQL Server 2000's Memory Management
> Facilities" by Ken Henderson:
> http://msdn.microsoft.com/library/d...ev_01262004.asp
> "... None of the tools you typically use to inspect application memory use
> (Task Manager, Perfmon/Sysmon, etc.) show the amount of AWE memory used by
> individual processes. There's no indication of the amount of AWE memory
> used by each process, nor is this memory included in the working set size
> reported for a given process ..."
> Thanks,
> -Ivan
> --Original Message--
> From: james
> Posted At: Tuesday, February 28, 2006 6:52 AM
> Posted To: microsoft.public.sqlserver.server
> Conversation: MemToLeave area! How to monitor?
> Subject: MemToLeave area! How to monitor?
>
> Gurus,
> Occasionally I get the error of "WARNING: Failed to reserve contiguous
> memory of Size= 65536."
> What is the unit for this size, is it bytes or KB? Additionally,
> I have set up 511 MB for MemToLeave area by adding -g384 for Sql2k SP3a on
> AWE enabled system. I have total of 16 GB of RAM, of which 14 GB is set up
> maximum for Sql server.
> If I look at Perfmon counter of Process->Private bytes for sql server
> process it gives me 224 MB.
> If I look at sqlserver.exe process on task manager it gives me 215MB.
> If I look at DBCC memorystatus, OS in use, it gives me 12 MB.
> I would like to know, How can I calculate exactly how much memory is being
> assigned and how much in use from MemToLeave area by looking at above
> mentioned counters or any other perfmon or dbcc counters?
> I really appreciate any input on this matter.|||James,
The unit of measure in the message you list is bytes, not KB. Basically,
the memory mgr is failing to reserve 64KB of memory.
The numbers you report from the various monitoring tools don't sound
surprising -- they all measure different things. For example,
Process:Private Bytes is a measure of _committed_ virtual memory, not
reserved. -G controls the region set aside for MTL, not committed or
reserved -- free. That virtual memory is reserved and committed as needed
by the various memory consumers running inside the SQL Server process.
Also, on SS2K, AWE can't be used for anything except caching data and index
pages. Regular MTL allocations never come from AWE.
Keep in mind that the MTL region is really not a region at all but just
refers to the memory left over once the BPool takes what it needs. It's the
unused virtual memory in the process's virtual address space. -G can grow
or shrink this area, but it basically only amounts to unused memory within
the process.
Allocations by external consumers (COM objects, xprocs (usually), OLEDB
providers, etc.) come from MTL. Also, allocations by the server itself that
are >8KB are serviced from MTL rather than the BPool. This just means that,
at some level, they call VirtualAlloc to allocate VM directly from Windows
rather than using pages already allocated to the BPool.
Accompanying the error message you list should be the equivalent of DBCC
MEMORYSTATUS output. This is more relevant than running the command
yourself because it's taken at the exact moment the error occurred. If I
were you, I'd have a look at the various buckets listed in that report to
see if any of them seem high. Keep in mind that many of them are page
counts, not byte counts, so you need to multiply them by 8KB to get the
exact byte count in use.
Also keep in mind that this error can be caused by extreme fragmentation as
well as over-allocation of memory. IOW, you could have well more than 64KB
available within the process, but no single contiguous block of that size or
larger.
If, after you've worked through the above, you still can't figure out why
the reservation is failing, you might want to contact PSS to help you
troubleshoot it further. They deal with these all the time and should be
able to get you fixed up in no time.
HTH,
-kh
"james" <kush@.brandes.com> wrote in message
news:%23hTPNHLPGHA.720@.TK2MSFTNGP14.phx.gbl...
> Thanks Ivan. I had already checked that article and also few other google
> search but didn't get the answer.
> <ivanpe@.online.microsoft.com> wrote in message
> news:OenNh9IPGHA.3840@.TK2MSFTNGP14.phx.gbl...
>
MemToLeave area! How to monitor?
Gurus,
Occasionally I get the error of "WARNING: Failed to reserve contiguous
memory of Size= 65536."
What is the unit for this size, is it bytes or KB? Additionally,
I have set up 511 MB for MemToLeave area by adding -g384 for Sql2k SP3a on
AWE enabled system. I have total of 16 GB of RAM, of which 14 GB is set up
maximum for Sql server.
If I look at Perfmon counter of Process->Private bytes for sql server
process it gives me 224 MB.
If I look at sqlserver.exe process on task manager it gives me 215MB.
If I look at DBCC memorystatus, OS in use, it gives me 12 MB.
I would like to know, How can I calculate exactly how much memory is being
assigned and how much in use from MemToLeave area by looking at above
mentioned counters or any other perfmon or dbcc counters?
I really appreciate any input on this matter.Please, take a look at "Inside SQL Server 2000's Memory Management Facilities" by Ken Henderson:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsqldev/html/sqldev_01262004.asp
"... None of the tools you typically use to inspect application memory use (Task Manager, Perfmon/Sysmon, etc.) show the amount of AWE memory used by individual processes. There's no indication of the amount of AWE memory used by each process, nor is this memory included in the working set size reported for a given process ..."
Thanks,
-Ivan
--Original Message--
From: james
Posted At: Tuesday, February 28, 2006 6:52 AM
Posted To: microsoft.public.sqlserver.server
Conversation: MemToLeave area! How to monitor?
Subject: MemToLeave area! How to monitor?
Gurus,
Occasionally I get the error of "WARNING: Failed to reserve contiguous memory of Size= 65536."
What is the unit for this size, is it bytes or KB? Additionally,
I have set up 511 MB for MemToLeave area by adding -g384 for Sql2k SP3a on AWE enabled system. I have total of 16 GB of RAM, of which 14 GB is set up maximum for Sql server.
If I look at Perfmon counter of Process->Private bytes for sql server process it gives me 224 MB.
If I look at sqlserver.exe process on task manager it gives me 215MB.
If I look at DBCC memorystatus, OS in use, it gives me 12 MB.
I would like to know, How can I calculate exactly how much memory is being assigned and how much in use from MemToLeave area by looking at above mentioned counters or any other perfmon or dbcc counters?
I really appreciate any input on this matter.|||Thanks Ivan. I had already checked that article and also few other google
search but didn't get the answer.
<ivanpe@.online.microsoft.com> wrote in message
news:OenNh9IPGHA.3840@.TK2MSFTNGP14.phx.gbl...
> Please, take a look at "Inside SQL Server 2000's Memory Management
> Facilities" by Ken Henderson:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsqldev/html/sqldev_01262004.asp
> "... None of the tools you typically use to inspect application memory use
> (Task Manager, Perfmon/Sysmon, etc.) show the amount of AWE memory used by
> individual processes. There's no indication of the amount of AWE memory
> used by each process, nor is this memory included in the working set size
> reported for a given process ..."
> Thanks,
> -Ivan
> --Original Message--
> From: james
> Posted At: Tuesday, February 28, 2006 6:52 AM
> Posted To: microsoft.public.sqlserver.server
> Conversation: MemToLeave area! How to monitor?
> Subject: MemToLeave area! How to monitor?
>
> Gurus,
> Occasionally I get the error of "WARNING: Failed to reserve contiguous
> memory of Size= 65536."
> What is the unit for this size, is it bytes or KB? Additionally,
> I have set up 511 MB for MemToLeave area by adding -g384 for Sql2k SP3a on
> AWE enabled system. I have total of 16 GB of RAM, of which 14 GB is set up
> maximum for Sql server.
> If I look at Perfmon counter of Process->Private bytes for sql server
> process it gives me 224 MB.
> If I look at sqlserver.exe process on task manager it gives me 215MB.
> If I look at DBCC memorystatus, OS in use, it gives me 12 MB.
> I would like to know, How can I calculate exactly how much memory is being
> assigned and how much in use from MemToLeave area by looking at above
> mentioned counters or any other perfmon or dbcc counters?
> I really appreciate any input on this matter.|||James,
The unit of measure in the message you list is bytes, not KB. Basically,
the memory mgr is failing to reserve 64KB of memory.
The numbers you report from the various monitoring tools don't sound
surprising -- they all measure different things. For example,
Process:Private Bytes is a measure of _committed_ virtual memory, not
reserved. -G controls the region set aside for MTL, not committed or
reserved -- free. That virtual memory is reserved and committed as needed
by the various memory consumers running inside the SQL Server process.
Also, on SS2K, AWE can't be used for anything except caching data and index
pages. Regular MTL allocations never come from AWE.
Keep in mind that the MTL region is really not a region at all but just
refers to the memory left over once the BPool takes what it needs. It's the
unused virtual memory in the process's virtual address space. -G can grow
or shrink this area, but it basically only amounts to unused memory within
the process.
Allocations by external consumers (COM objects, xprocs (usually), OLEDB
providers, etc.) come from MTL. Also, allocations by the server itself that
are >8KB are serviced from MTL rather than the BPool. This just means that,
at some level, they call VirtualAlloc to allocate VM directly from Windows
rather than using pages already allocated to the BPool.
Accompanying the error message you list should be the equivalent of DBCC
MEMORYSTATUS output. This is more relevant than running the command
yourself because it's taken at the exact moment the error occurred. If I
were you, I'd have a look at the various buckets listed in that report to
see if any of them seem high. Keep in mind that many of them are page
counts, not byte counts, so you need to multiply them by 8KB to get the
exact byte count in use.
Also keep in mind that this error can be caused by extreme fragmentation as
well as over-allocation of memory. IOW, you could have well more than 64KB
available within the process, but no single contiguous block of that size or
larger.
If, after you've worked through the above, you still can't figure out why
the reservation is failing, you might want to contact PSS to help you
troubleshoot it further. They deal with these all the time and should be
able to get you fixed up in no time.
HTH,
-kh
"james" <kush@.brandes.com> wrote in message
news:%23hTPNHLPGHA.720@.TK2MSFTNGP14.phx.gbl...
> Thanks Ivan. I had already checked that article and also few other google
> search but didn't get the answer.
> <ivanpe@.online.microsoft.com> wrote in message
> news:OenNh9IPGHA.3840@.TK2MSFTNGP14.phx.gbl...
>> Please, take a look at "Inside SQL Server 2000's Memory Management
>> Facilities" by Ken Henderson:
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsqldev/html/sqldev_01262004.asp
>> "... None of the tools you typically use to inspect application memory
>> use (Task Manager, Perfmon/Sysmon, etc.) show the amount of AWE memory
>> used by individual processes. There's no indication of the amount of AWE
>> memory used by each process, nor is this memory included in the working
>> set size reported for a given process ..."
>> Thanks,
>> -Ivan
>> --Original Message--
>> From: james
>> Posted At: Tuesday, February 28, 2006 6:52 AM
>> Posted To: microsoft.public.sqlserver.server
>> Conversation: MemToLeave area! How to monitor?
>> Subject: MemToLeave area! How to monitor?
>>
>> Gurus,
>> Occasionally I get the error of "WARNING: Failed to reserve contiguous
>> memory of Size= 65536."
>> What is the unit for this size, is it bytes or KB? Additionally,
>> I have set up 511 MB for MemToLeave area by adding -g384 for Sql2k SP3a
>> on AWE enabled system. I have total of 16 GB of RAM, of which 14 GB is
>> set up maximum for Sql server.
>> If I look at Perfmon counter of Process->Private bytes for sql server
>> process it gives me 224 MB.
>> If I look at sqlserver.exe process on task manager it gives me 215MB.
>> If I look at DBCC memorystatus, OS in use, it gives me 12 MB.
>> I would like to know, How can I calculate exactly how much memory is
>> being assigned and how much in use from MemToLeave area by looking at
>> above mentioned counters or any other perfmon or dbcc counters?
>> I really appreciate any input on this matter.
>
Occasionally I get the error of "WARNING: Failed to reserve contiguous
memory of Size= 65536."
What is the unit for this size, is it bytes or KB? Additionally,
I have set up 511 MB for MemToLeave area by adding -g384 for Sql2k SP3a on
AWE enabled system. I have total of 16 GB of RAM, of which 14 GB is set up
maximum for Sql server.
If I look at Perfmon counter of Process->Private bytes for sql server
process it gives me 224 MB.
If I look at sqlserver.exe process on task manager it gives me 215MB.
If I look at DBCC memorystatus, OS in use, it gives me 12 MB.
I would like to know, How can I calculate exactly how much memory is being
assigned and how much in use from MemToLeave area by looking at above
mentioned counters or any other perfmon or dbcc counters?
I really appreciate any input on this matter.Please, take a look at "Inside SQL Server 2000's Memory Management Facilities" by Ken Henderson:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsqldev/html/sqldev_01262004.asp
"... None of the tools you typically use to inspect application memory use (Task Manager, Perfmon/Sysmon, etc.) show the amount of AWE memory used by individual processes. There's no indication of the amount of AWE memory used by each process, nor is this memory included in the working set size reported for a given process ..."
Thanks,
-Ivan
--Original Message--
From: james
Posted At: Tuesday, February 28, 2006 6:52 AM
Posted To: microsoft.public.sqlserver.server
Conversation: MemToLeave area! How to monitor?
Subject: MemToLeave area! How to monitor?
Gurus,
Occasionally I get the error of "WARNING: Failed to reserve contiguous memory of Size= 65536."
What is the unit for this size, is it bytes or KB? Additionally,
I have set up 511 MB for MemToLeave area by adding -g384 for Sql2k SP3a on AWE enabled system. I have total of 16 GB of RAM, of which 14 GB is set up maximum for Sql server.
If I look at Perfmon counter of Process->Private bytes for sql server process it gives me 224 MB.
If I look at sqlserver.exe process on task manager it gives me 215MB.
If I look at DBCC memorystatus, OS in use, it gives me 12 MB.
I would like to know, How can I calculate exactly how much memory is being assigned and how much in use from MemToLeave area by looking at above mentioned counters or any other perfmon or dbcc counters?
I really appreciate any input on this matter.|||Thanks Ivan. I had already checked that article and also few other google
search but didn't get the answer.
<ivanpe@.online.microsoft.com> wrote in message
news:OenNh9IPGHA.3840@.TK2MSFTNGP14.phx.gbl...
> Please, take a look at "Inside SQL Server 2000's Memory Management
> Facilities" by Ken Henderson:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsqldev/html/sqldev_01262004.asp
> "... None of the tools you typically use to inspect application memory use
> (Task Manager, Perfmon/Sysmon, etc.) show the amount of AWE memory used by
> individual processes. There's no indication of the amount of AWE memory
> used by each process, nor is this memory included in the working set size
> reported for a given process ..."
> Thanks,
> -Ivan
> --Original Message--
> From: james
> Posted At: Tuesday, February 28, 2006 6:52 AM
> Posted To: microsoft.public.sqlserver.server
> Conversation: MemToLeave area! How to monitor?
> Subject: MemToLeave area! How to monitor?
>
> Gurus,
> Occasionally I get the error of "WARNING: Failed to reserve contiguous
> memory of Size= 65536."
> What is the unit for this size, is it bytes or KB? Additionally,
> I have set up 511 MB for MemToLeave area by adding -g384 for Sql2k SP3a on
> AWE enabled system. I have total of 16 GB of RAM, of which 14 GB is set up
> maximum for Sql server.
> If I look at Perfmon counter of Process->Private bytes for sql server
> process it gives me 224 MB.
> If I look at sqlserver.exe process on task manager it gives me 215MB.
> If I look at DBCC memorystatus, OS in use, it gives me 12 MB.
> I would like to know, How can I calculate exactly how much memory is being
> assigned and how much in use from MemToLeave area by looking at above
> mentioned counters or any other perfmon or dbcc counters?
> I really appreciate any input on this matter.|||James,
The unit of measure in the message you list is bytes, not KB. Basically,
the memory mgr is failing to reserve 64KB of memory.
The numbers you report from the various monitoring tools don't sound
surprising -- they all measure different things. For example,
Process:Private Bytes is a measure of _committed_ virtual memory, not
reserved. -G controls the region set aside for MTL, not committed or
reserved -- free. That virtual memory is reserved and committed as needed
by the various memory consumers running inside the SQL Server process.
Also, on SS2K, AWE can't be used for anything except caching data and index
pages. Regular MTL allocations never come from AWE.
Keep in mind that the MTL region is really not a region at all but just
refers to the memory left over once the BPool takes what it needs. It's the
unused virtual memory in the process's virtual address space. -G can grow
or shrink this area, but it basically only amounts to unused memory within
the process.
Allocations by external consumers (COM objects, xprocs (usually), OLEDB
providers, etc.) come from MTL. Also, allocations by the server itself that
are >8KB are serviced from MTL rather than the BPool. This just means that,
at some level, they call VirtualAlloc to allocate VM directly from Windows
rather than using pages already allocated to the BPool.
Accompanying the error message you list should be the equivalent of DBCC
MEMORYSTATUS output. This is more relevant than running the command
yourself because it's taken at the exact moment the error occurred. If I
were you, I'd have a look at the various buckets listed in that report to
see if any of them seem high. Keep in mind that many of them are page
counts, not byte counts, so you need to multiply them by 8KB to get the
exact byte count in use.
Also keep in mind that this error can be caused by extreme fragmentation as
well as over-allocation of memory. IOW, you could have well more than 64KB
available within the process, but no single contiguous block of that size or
larger.
If, after you've worked through the above, you still can't figure out why
the reservation is failing, you might want to contact PSS to help you
troubleshoot it further. They deal with these all the time and should be
able to get you fixed up in no time.
HTH,
-kh
"james" <kush@.brandes.com> wrote in message
news:%23hTPNHLPGHA.720@.TK2MSFTNGP14.phx.gbl...
> Thanks Ivan. I had already checked that article and also few other google
> search but didn't get the answer.
> <ivanpe@.online.microsoft.com> wrote in message
> news:OenNh9IPGHA.3840@.TK2MSFTNGP14.phx.gbl...
>> Please, take a look at "Inside SQL Server 2000's Memory Management
>> Facilities" by Ken Henderson:
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsqldev/html/sqldev_01262004.asp
>> "... None of the tools you typically use to inspect application memory
>> use (Task Manager, Perfmon/Sysmon, etc.) show the amount of AWE memory
>> used by individual processes. There's no indication of the amount of AWE
>> memory used by each process, nor is this memory included in the working
>> set size reported for a given process ..."
>> Thanks,
>> -Ivan
>> --Original Message--
>> From: james
>> Posted At: Tuesday, February 28, 2006 6:52 AM
>> Posted To: microsoft.public.sqlserver.server
>> Conversation: MemToLeave area! How to monitor?
>> Subject: MemToLeave area! How to monitor?
>>
>> Gurus,
>> Occasionally I get the error of "WARNING: Failed to reserve contiguous
>> memory of Size= 65536."
>> What is the unit for this size, is it bytes or KB? Additionally,
>> I have set up 511 MB for MemToLeave area by adding -g384 for Sql2k SP3a
>> on AWE enabled system. I have total of 16 GB of RAM, of which 14 GB is
>> set up maximum for Sql server.
>> If I look at Perfmon counter of Process->Private bytes for sql server
>> process it gives me 224 MB.
>> If I look at sqlserver.exe process on task manager it gives me 215MB.
>> If I look at DBCC memorystatus, OS in use, it gives me 12 MB.
>> I would like to know, How can I calculate exactly how much memory is
>> being assigned and how much in use from MemToLeave area by looking at
>> above mentioned counters or any other perfmon or dbcc counters?
>> I really appreciate any input on this matter.
>
MemToLeave and Thirdy Pary DLLs
Hi
I've been running into problems with a server that indicate that space in the
MemToLeave area is exhausted. The messages in the error log are along the
lines of 'Failed to reserve contigous memory', 'Clearing procedure cache to
free contigous memory' et cetera.
We do have a third party DLL in use and I've seen in a previous post a
recommendation to move third party DLLs out of the production server's
address space. The question is how to do this? My NT administrators don't
know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I can
do once a problem has occurred, but is there a way of ensuring the DLL is
always out of the server's address space?
If I unload the DLL what is to stop it meing reloaded, as it is used by
database monitoring software that runs every two minutes?
I'm also a little confused by the -g startup setting.
One post I've seen says to set it to 384 to increase the space available to
the MEmToLeave. Another post states that you need 128M for the worker threads
and using the default -g will add another 256M, bringing the default to 384M.
BOL is woolly on the subject, as normal.
Thanks
Mark
Message posted via http://www.droptable.com
Hi Mark
Some .dll's are designed to be run either in-process or ex-process & some
are simply designed to run in-process, so some can be forced to run
ex-process & some can't.
The type that typically *can* be run ex-process from SQL Server are COM type
..dlls, typically developed in VB6.0 (but can also be developed in Delphi,
C++ or J++0). you know you're dealing with one of these if the calling code
uses the sp_OACreate syntax. To make these guys run ex-process, you
configure them to run within COM+ or (or MTS on older WinNT) context, which
requires registering them in COM+.
The type that typcially *cannot* be run ex-process from SQL Server are
Extended Stored procedures, which are typically written in C and simply
aren't designed to be run ex-process. So if you're talking about a .dll
which is registered as an Extended Stored Proc, you probably won't be able
to make it run ex-process.
The post about the -g switch is correct. SQL Server's allocation of memory
during startup is best documented in Ken Henderson's Internals Guru's Guide
book. He's also written articles on SQL Memory Management, one of which is
here:
http://msdn.microsoft.com/data/defau...v_01262004.asp
But I dono't think this one specifically covers the -g switch in the detail
you're after. Try to get hold of the book, as it'd definitely covered in
detail in its Memory chapter.
HTH
Regards,
Greg Linwood
SQL Server MVP
"mpenfold via droptable.com" <u16092@.uwe> wrote in message
news:58090a9e28698@.uwe...
> Hi
> I've been running into problems with a server that indicate that space in
> the
> MemToLeave area is exhausted. The messages in the error log are along the
> lines of 'Failed to reserve contigous memory', 'Clearing procedure cache
> to
> free contigous memory' et cetera.
> We do have a third party DLL in use and I've seen in a previous post a
> recommendation to move third party DLLs out of the production server's
> address space. The question is how to do this? My NT administrators don't
> know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I
> can
> do once a problem has occurred, but is there a way of ensuring the DLL is
> always out of the server's address space?
> If I unload the DLL what is to stop it meing reloaded, as it is used by
> database monitoring software that runs every two minutes?
> I'm also a little confused by the -g startup setting.
> One post I've seen says to set it to 384 to increase the space available
> to
> the MEmToLeave. Another post states that you need 128M for the worker
> threads
> and using the default -g will add another 256M, bringing the default to
> 384M.
> BOL is woolly on the subject, as normal.
> Thanks
> Mark
> --
> Message posted via http://www.droptable.com
I've been running into problems with a server that indicate that space in the
MemToLeave area is exhausted. The messages in the error log are along the
lines of 'Failed to reserve contigous memory', 'Clearing procedure cache to
free contigous memory' et cetera.
We do have a third party DLL in use and I've seen in a previous post a
recommendation to move third party DLLs out of the production server's
address space. The question is how to do this? My NT administrators don't
know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I can
do once a problem has occurred, but is there a way of ensuring the DLL is
always out of the server's address space?
If I unload the DLL what is to stop it meing reloaded, as it is used by
database monitoring software that runs every two minutes?
I'm also a little confused by the -g startup setting.
One post I've seen says to set it to 384 to increase the space available to
the MEmToLeave. Another post states that you need 128M for the worker threads
and using the default -g will add another 256M, bringing the default to 384M.
BOL is woolly on the subject, as normal.
Thanks
Mark
Message posted via http://www.droptable.com
Hi Mark
Some .dll's are designed to be run either in-process or ex-process & some
are simply designed to run in-process, so some can be forced to run
ex-process & some can't.
The type that typically *can* be run ex-process from SQL Server are COM type
..dlls, typically developed in VB6.0 (but can also be developed in Delphi,
C++ or J++0). you know you're dealing with one of these if the calling code
uses the sp_OACreate syntax. To make these guys run ex-process, you
configure them to run within COM+ or (or MTS on older WinNT) context, which
requires registering them in COM+.
The type that typcially *cannot* be run ex-process from SQL Server are
Extended Stored procedures, which are typically written in C and simply
aren't designed to be run ex-process. So if you're talking about a .dll
which is registered as an Extended Stored Proc, you probably won't be able
to make it run ex-process.
The post about the -g switch is correct. SQL Server's allocation of memory
during startup is best documented in Ken Henderson's Internals Guru's Guide
book. He's also written articles on SQL Memory Management, one of which is
here:
http://msdn.microsoft.com/data/defau...v_01262004.asp
But I dono't think this one specifically covers the -g switch in the detail
you're after. Try to get hold of the book, as it'd definitely covered in
detail in its Memory chapter.
HTH
Regards,
Greg Linwood
SQL Server MVP
"mpenfold via droptable.com" <u16092@.uwe> wrote in message
news:58090a9e28698@.uwe...
> Hi
> I've been running into problems with a server that indicate that space in
> the
> MemToLeave area is exhausted. The messages in the error log are along the
> lines of 'Failed to reserve contigous memory', 'Clearing procedure cache
> to
> free contigous memory' et cetera.
> We do have a third party DLL in use and I've seen in a previous post a
> recommendation to move third party DLLs out of the production server's
> address space. The question is how to do this? My NT administrators don't
> know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I
> can
> do once a problem has occurred, but is there a way of ensuring the DLL is
> always out of the server's address space?
> If I unload the DLL what is to stop it meing reloaded, as it is used by
> database monitoring software that runs every two minutes?
> I'm also a little confused by the -g startup setting.
> One post I've seen says to set it to 384 to increase the space available
> to
> the MEmToLeave. Another post states that you need 128M for the worker
> threads
> and using the default -g will add another 256M, bringing the default to
> 384M.
> BOL is woolly on the subject, as normal.
> Thanks
> Mark
> --
> Message posted via http://www.droptable.com
MemToLeave and Thirdy Pary DLLs
Hi
I've been running into problems with a server that indicate that space in the
MemToLeave area is exhausted. The messages in the error log are along the
lines of 'Failed to reserve contigous memory', 'Clearing procedure cache to
free contigous memory' et cetera.
We do have a third party DLL in use and I've seen in a previous post a
recommendation to move third party DLLs out of the production server's
address space. The question is how to do this? My NT administrators don't
know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I can
do once a problem has occurred, but is there a way of ensuring the DLL is
always out of the server's address space?
If I unload the DLL what is to stop it meing reloaded, as it is used by
database monitoring software that runs every two minutes?
I'm also a little confused by the -g startup setting.
One post I've seen says to set it to 384 to increase the space available to
the MEmToLeave. Another post states that you need 128M for the worker threads
and using the default -g will add another 256M, bringing the default to 384M.
BOL is woolly on the subject, as normal.
Thanks
Mark
--
Message posted via http://www.sqlmonster.comHi Mark
Some .dll's are designed to be run either in-process or ex-process & some
are simply designed to run in-process, so some can be forced to run
ex-process & some can't.
The type that typically *can* be run ex-process from SQL Server are COM type
.dlls, typically developed in VB6.0 (but can also be developed in Delphi,
C++ or J++0). you know you're dealing with one of these if the calling code
uses the sp_OACreate syntax. To make these guys run ex-process, you
configure them to run within COM+ or (or MTS on older WinNT) context, which
requires registering them in COM+.
The type that typcially *cannot* be run ex-process from SQL Server are
Extended Stored procedures, which are typically written in C and simply
aren't designed to be run ex-process. So if you're talking about a .dll
which is registered as an Extended Stored Proc, you probably won't be able
to make it run ex-process.
The post about the -g switch is correct. SQL Server's allocation of memory
during startup is best documented in Ken Henderson's Internals Guru's Guide
book. He's also written articles on SQL Memory Management, one of which is
here:
http://msdn.microsoft.com/data/default.aspx?pull=/library/en-us/dnsqldev/html/sqldev_01262004.asp
But I dono't think this one specifically covers the -g switch in the detail
you're after. Try to get hold of the book, as it'd definitely covered in
detail in its Memory chapter.
HTH
Regards,
Greg Linwood
SQL Server MVP
"mpenfold via SQLMonster.com" <u16092@.uwe> wrote in message
news:58090a9e28698@.uwe...
> Hi
> I've been running into problems with a server that indicate that space in
> the
> MemToLeave area is exhausted. The messages in the error log are along the
> lines of 'Failed to reserve contigous memory', 'Clearing procedure cache
> to
> free contigous memory' et cetera.
> We do have a third party DLL in use and I've seen in a previous post a
> recommendation to move third party DLLs out of the production server's
> address space. The question is how to do this? My NT administrators don't
> know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I
> can
> do once a problem has occurred, but is there a way of ensuring the DLL is
> always out of the server's address space?
> If I unload the DLL what is to stop it meing reloaded, as it is used by
> database monitoring software that runs every two minutes?
> I'm also a little confused by the -g startup setting.
> One post I've seen says to set it to 384 to increase the space available
> to
> the MEmToLeave. Another post states that you need 128M for the worker
> threads
> and using the default -g will add another 256M, bringing the default to
> 384M.
> BOL is woolly on the subject, as normal.
> Thanks
> Mark
> --
> Message posted via http://www.sqlmonster.comsql
I've been running into problems with a server that indicate that space in the
MemToLeave area is exhausted. The messages in the error log are along the
lines of 'Failed to reserve contigous memory', 'Clearing procedure cache to
free contigous memory' et cetera.
We do have a third party DLL in use and I've seen in a previous post a
recommendation to move third party DLLs out of the production server's
address space. The question is how to do this? My NT administrators don't
know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I can
do once a problem has occurred, but is there a way of ensuring the DLL is
always out of the server's address space?
If I unload the DLL what is to stop it meing reloaded, as it is used by
database monitoring software that runs every two minutes?
I'm also a little confused by the -g startup setting.
One post I've seen says to set it to 384 to increase the space available to
the MEmToLeave. Another post states that you need 128M for the worker threads
and using the default -g will add another 256M, bringing the default to 384M.
BOL is woolly on the subject, as normal.
Thanks
Mark
--
Message posted via http://www.sqlmonster.comHi Mark
Some .dll's are designed to be run either in-process or ex-process & some
are simply designed to run in-process, so some can be forced to run
ex-process & some can't.
The type that typically *can* be run ex-process from SQL Server are COM type
.dlls, typically developed in VB6.0 (but can also be developed in Delphi,
C++ or J++0). you know you're dealing with one of these if the calling code
uses the sp_OACreate syntax. To make these guys run ex-process, you
configure them to run within COM+ or (or MTS on older WinNT) context, which
requires registering them in COM+.
The type that typcially *cannot* be run ex-process from SQL Server are
Extended Stored procedures, which are typically written in C and simply
aren't designed to be run ex-process. So if you're talking about a .dll
which is registered as an Extended Stored Proc, you probably won't be able
to make it run ex-process.
The post about the -g switch is correct. SQL Server's allocation of memory
during startup is best documented in Ken Henderson's Internals Guru's Guide
book. He's also written articles on SQL Memory Management, one of which is
here:
http://msdn.microsoft.com/data/default.aspx?pull=/library/en-us/dnsqldev/html/sqldev_01262004.asp
But I dono't think this one specifically covers the -g switch in the detail
you're after. Try to get hold of the book, as it'd definitely covered in
detail in its Memory chapter.
HTH
Regards,
Greg Linwood
SQL Server MVP
"mpenfold via SQLMonster.com" <u16092@.uwe> wrote in message
news:58090a9e28698@.uwe...
> Hi
> I've been running into problems with a server that indicate that space in
> the
> MemToLeave area is exhausted. The messages in the error log are along the
> lines of 'Failed to reserve contigous memory', 'Clearing procedure cache
> to
> free contigous memory' et cetera.
> We do have a third party DLL in use and I've seen in a previous post a
> recommendation to move third party DLLs out of the production server's
> address space. The question is how to do this? My NT administrators don't
> know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I
> can
> do once a problem has occurred, but is there a way of ensuring the DLL is
> always out of the server's address space?
> If I unload the DLL what is to stop it meing reloaded, as it is used by
> database monitoring software that runs every two minutes?
> I'm also a little confused by the -g startup setting.
> One post I've seen says to set it to 384 to increase the space available
> to
> the MEmToLeave. Another post states that you need 128M for the worker
> threads
> and using the default -g will add another 256M, bringing the default to
> 384M.
> BOL is woolly on the subject, as normal.
> Thanks
> Mark
> --
> Message posted via http://www.sqlmonster.comsql
MemToLeave and Thirdy Pary DLLs
Hi
I've been running into problems with a server that indicate that space in th
e
MemToLeave area is exhausted. The messages in the error log are along the
lines of 'Failed to reserve contigous memory', 'Clearing procedure cache to
free contigous memory' et cetera.
We do have a third party DLL in use and I've seen in a previous post a
recommendation to move third party DLLs out of the production server's
address space. The question is how to do this? My NT administrators don't
know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I can
do once a problem has occurred, but is there a way of ensuring the DLL is
always out of the server's address space?
If I unload the DLL what is to stop it meing reloaded, as it is used by
database monitoring software that runs every two minutes?
I'm also a little confused by the -g startup setting.
One post I've seen says to set it to 384 to increase the space available to
the MEmToLeave. Another post states that you need 128M for the worker thread
s
and using the default -g will add another 256M, bringing the default to 384M
.
BOL is woolly on the subject, as normal.
Thanks
Mark
Message posted via http://www.droptable.comHi Mark
Some .dll's are designed to be run either in-process or ex-process & some
are simply designed to run in-process, so some can be forced to run
ex-process & some can't.
The type that typically *can* be run ex-process from SQL Server are COM type
.dlls, typically developed in VB6.0 (but can also be developed in Delphi,
C++ or J++0). you know you're dealing with one of these if the calling code
uses the sp_OACreate syntax. To make these guys run ex-process, you
configure them to run within COM+ or (or MTS on older WinNT) context, which
requires registering them in COM+.
The type that typcially *cannot* be run ex-process from SQL Server are
Extended Stored procedures, which are typically written in C and simply
aren't designed to be run ex-process. So if you're talking about a .dll
which is registered as an Extended Stored Proc, you probably won't be able
to make it run ex-process.
The post about the -g switch is correct. SQL Server's allocation of memory
during startup is best documented in Ken Henderson's Internals Guru's Guide
book. He's also written articles on SQL Memory Management, one of which is
here:
http://msdn.microsoft.com/data/defa...ev_01262004.asp
But I dono't think this one specifically covers the -g switch in the detail
you're after. Try to get hold of the book, as it'd definitely covered in
detail in its Memory chapter.
HTH
Regards,
Greg Linwood
SQL Server MVP
"mpenfold via droptable.com" <u16092@.uwe> wrote in message
news:58090a9e28698@.uwe...
> Hi
> I've been running into problems with a server that indicate that space in
> the
> MemToLeave area is exhausted. The messages in the error log are along the
> lines of 'Failed to reserve contigous memory', 'Clearing procedure cache
> to
> free contigous memory' et cetera.
> We do have a third party DLL in use and I've seen in a previous post a
> recommendation to move third party DLLs out of the production server's
> address space. The question is how to do this? My NT administrators don't
> know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I
> can
> do once a problem has occurred, but is there a way of ensuring the DLL is
> always out of the server's address space?
> If I unload the DLL what is to stop it meing reloaded, as it is used by
> database monitoring software that runs every two minutes?
> I'm also a little confused by the -g startup setting.
> One post I've seen says to set it to 384 to increase the space available
> to
> the MEmToLeave. Another post states that you need 128M for the worker
> threads
> and using the default -g will add another 256M, bringing the default to
> 384M.
> BOL is woolly on the subject, as normal.
> Thanks
> Mark
> --
> Message posted via http://www.droptable.com
I've been running into problems with a server that indicate that space in th
e
MemToLeave area is exhausted. The messages in the error log are along the
lines of 'Failed to reserve contigous memory', 'Clearing procedure cache to
free contigous memory' et cetera.
We do have a third party DLL in use and I've seen in a previous post a
recommendation to move third party DLLs out of the production server's
address space. The question is how to do this? My NT administrators don't
know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I can
do once a problem has occurred, but is there a way of ensuring the DLL is
always out of the server's address space?
If I unload the DLL what is to stop it meing reloaded, as it is used by
database monitoring software that runs every two minutes?
I'm also a little confused by the -g startup setting.
One post I've seen says to set it to 384 to increase the space available to
the MEmToLeave. Another post states that you need 128M for the worker thread
s
and using the default -g will add another 256M, bringing the default to 384M
.
BOL is woolly on the subject, as normal.
Thanks
Mark
Message posted via http://www.droptable.comHi Mark
Some .dll's are designed to be run either in-process or ex-process & some
are simply designed to run in-process, so some can be forced to run
ex-process & some can't.
The type that typically *can* be run ex-process from SQL Server are COM type
.dlls, typically developed in VB6.0 (but can also be developed in Delphi,
C++ or J++0). you know you're dealing with one of these if the calling code
uses the sp_OACreate syntax. To make these guys run ex-process, you
configure them to run within COM+ or (or MTS on older WinNT) context, which
requires registering them in COM+.
The type that typcially *cannot* be run ex-process from SQL Server are
Extended Stored procedures, which are typically written in C and simply
aren't designed to be run ex-process. So if you're talking about a .dll
which is registered as an Extended Stored Proc, you probably won't be able
to make it run ex-process.
The post about the -g switch is correct. SQL Server's allocation of memory
during startup is best documented in Ken Henderson's Internals Guru's Guide
book. He's also written articles on SQL Memory Management, one of which is
here:
http://msdn.microsoft.com/data/defa...ev_01262004.asp
But I dono't think this one specifically covers the -g switch in the detail
you're after. Try to get hold of the book, as it'd definitely covered in
detail in its Memory chapter.
HTH
Regards,
Greg Linwood
SQL Server MVP
"mpenfold via droptable.com" <u16092@.uwe> wrote in message
news:58090a9e28698@.uwe...
> Hi
> I've been running into problems with a server that indicate that space in
> the
> MemToLeave area is exhausted. The messages in the error log are along the
> lines of 'Failed to reserve contigous memory', 'Clearing procedure cache
> to
> free contigous memory' et cetera.
> We do have a third party DLL in use and I've seen in a previous post a
> recommendation to move third party DLLs out of the production server's
> address space. The question is how to do this? My NT administrators don't
> know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I
> can
> do once a problem has occurred, but is there a way of ensuring the DLL is
> always out of the server's address space?
> If I unload the DLL what is to stop it meing reloaded, as it is used by
> database monitoring software that runs every two minutes?
> I'm also a little confused by the -g startup setting.
> One post I've seen says to set it to 384 to increase the space available
> to
> the MEmToLeave. Another post states that you need 128M for the worker
> threads
> and using the default -g will add another 256M, bringing the default to
> 384M.
> BOL is woolly on the subject, as normal.
> Thanks
> Mark
> --
> Message posted via http://www.droptable.com
Subscribe to:
Posts (Atom)