Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

What process is consuming my VAS Reservation Expand / Collapse
Author
Message
Posted Friday, January 18, 2013 2:34 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, July 22, 2013 9:32 PM
Points: 3, Visits: 35
I am encountering an error on one of our environments where further logins are not allowed anymore. Only way to resolve the problem is to restart the SQLServer Instance.

Different SQL Memory Changes were done on the instance from Enabling/Disabling AWE, changing min and max memory to adding -g to the startup option.

Environment is 32bit, SQL Server 2005 SP3. Memory on the server is 4GB.

After reading several articles, I started monitoring the VAS reservation. I used the query stated on this link http://sqlblogcasts.com/blogs/christian/archive/2008/01/07/sql-server-memtoleave-vas-and-64-bit.aspx

Currently AWE is enabled on the instance with max memory of 2.4GB. The -g512 was added to the startup parameter. However, it only prolonged the error being encountered. Usually, the error occurs(further logins not allowed) when Max Free Size goes down to 2MB.

From what I read, the resources/processes that is using the VAS are the ff:
1) Any OLE/COM components loaded in SQL Server
2) Extended Stored Procedures
3) SQL Mail components
4) Any prepared documents using sp_xml_preparedocument
5) Linked Server Providers
6) Large Plans stored in Procedure Cache
7) Very frequent Backups also may cause MTL area depletion.
8) SQL CLR

Are there any DMVs I could check to pinpoint which of these components is consuming the VAS? Or are there procedures to troubleshoot the problem?

Any suggestions, links and ideas are welcome

Thanks In advance
Post #1408770
Posted Friday, January 18, 2013 7:17 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 10:52 PM
Points: 7,094, Visits: 12,579
From Understanding the VAS Reservation (aka MemToLeave) in SQL Server by Jonathan Kehayias this shows you the clerks using VAS in detail:

SELECT type, virtual_memory_committed_kb, multi_pages_kb 
FROM sys.dm_os_memory_clerks
WHERE virtual_memory_committed_kb > 0 OR multi_pages_kb > 0



__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato
Post #1408903
Posted Sunday, January 20, 2013 7:55 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, July 22, 2013 9:32 PM
Points: 3, Visits: 35
Thanks for the reply.

Did run the query and got the these result:

type virtual_memory_committed_kb multi_pages_kb
MEMORYCLERK_SQLBUFFERPOOL 6848 1144
OBJECTSTORE_LOCK_MANAGER 4096 0
MEMORYCLERK_SQLSTORENG 1152 56
MEMORYCLERK_SQLUTILITIES 240 0
MEMORYCLERK_SOSNODE 0 6072
MEMORYCLERK_SOSNODE 0 2800
MEMORYCLERK_SQLGENERAL 0 2456
CACHESTORE_SQLCP 0 344
MEMORYCLERK_SQLSERVICEBROKER 0 192
CACHESTORE_OBJCP 0 112
MEMORYCLERK_SQLOPTIMIZER 0 88
MEMORYCLERK_HOST 0 64
MEMORYCLERK_SNI 0 16
MEMORYCLERK_SNI 0 16
CACHESTORE_STACKFRAMES 0 8
OBJECTSTORE_SNI_PACKET 0 8
OBJECTSTORE_SNI_PACKET 0 8
OBJECTSTORE_SNI_PACKET 0 8
OBJECTSTORE_SNI_PACKET 0 8
OBJECTSTORE_SNI_PACKET 0 8
OBJECTSTORE_SNI_PACKET 0 8
CACHESTORE_STACKFRAMES 0 8
OBJECTSTORE_SNI_PACKET 0 8
OBJECTSTORE_SNI_PACKET 0 8
OBJECTSTORE_SNI_PACKET 0 8
OBJECTSTORE_SNI_PACKET 0 8
OBJECTSTORE_SNI_PACKET 0 8
OBJECTSTORE_SNI_PACKET 0 8

From the information gathered, how could I actually pinpoint which processes is consuming VAS. Which clerks actually relates to dblinks, CLR, etc.

Thanks in advance.

Post #1409338
Posted Sunday, January 20, 2013 10:23 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 10:52 PM
Points: 7,094, Visits: 12,579
Nothing is really standing out as holding onto a large amount of virtual memory at the moment. You can also have this issue if the VAS becomes fragmented and there no way to defragment it short of rebooting. What are you using to do backups? Are you running any third-party products or extended stored procedures on the server?

The best move really would be to move onto a 64-bit platform.


__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato
Post #1409351
Posted Sunday, January 20, 2013 11:20 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, July 22, 2013 9:32 PM
Points: 3, Visits: 35
Thanks again for the reply...

We don't have 3rd Party backup software as we are using Maintenance Plans for our backup. As with extended stored procedures also. Will have to verify this one. Is there any view to check if this is actually being used?

What we have are DBLinks to SQL server, Oracle and DB2 databases. I am suspecting this is eating up the VAS.
Post #1409363
Posted Monday, January 21, 2013 7:01 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 10:52 PM
Points: 7,094, Visits: 12,579
sqlserverdba1316 (1/20/2013)
Thanks again for the reply...

We don't have 3rd Party backup software as we are using Maintenance Plans for our backup. As with extended stored procedures also. Will have to verify this one. Is there any view to check if this is actually being used?


USE master;
SELECT * FROM sys.extended_procedures;

What we have are DBLinks to SQL server, Oracle and DB2 databases. I am suspecting this is eating up the VAS.

Use of Linked Servers can easily be the cause of something like what you're seeing. I have dealt with the problem you are seeing on 32-bit SQL 2005 SP4 and it was traced to a combination of third-party extended stored procedures (XSP) that were part of the backup software being used and Linked Server usage. I could show that after reboot an initial select from one of the Linked Servers on the instance (to a MySQL instance) would drop the largest VAS chunk avaialble significantly. To mitigate the issue the server was rebooted weekly every weekend. The final resolution was to upgrade to a 64-bit version of SQL Server.


edit: fix quote tags


__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato
Post #1409534
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse