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 ««12

Performance issue due to high memory usage Expand / Collapse
Author
Message
Posted Saturday, January 05, 2013 3:22 PM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Yesterday @ 3:30 PM
Points: 41,531, Visits: 34,448
SQLCrazyCertified (1/5/2013)
So, if I understand you correctly, if SQL uses all the memory which is allocated to it, then SQL will not have enough memory to work on other outstanding processes


Huh?
SQL uses its memory for all its processes, for the data cache, the plan cache and the several other caches that it has and for anything else it needs memory for.

If that's the case how can you say it's the normal expected behavior?


Because it is normal, expected behaviour.

It would not be efficient for SQL to request memory from the OS for one process, release it when that process is done, request memory from the OS for another, release, etc. If it did, it would be spending huge amounts of time and resources requesting and and releasing memory rather than actually doing productive work. Hence it requests memory, does not release it (unless the OS complains) and manages it after that point.

See the book I previously referenced, chapter 4.



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1403283
Posted Saturday, January 05, 2013 3:29 PM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, February 24, 2014 1:04 PM
Points: 383, Visits: 2,351
Ok. Thank you. I will read further.

SueTons.


Regards,
SQLisAwe5oMe.
Post #1403286
Posted Saturday, January 05, 2013 3:55 PM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Yesterday @ 9:30 PM
Points: 20,467, Visits: 14,104
SQLCrazyCertified (1/4/2013)
SQLRNNR, There are only 50 active connections.....so, I don't think this is the issue.

Joie Andrew, Had complains that everything is running slow and I coudn't find anything else other than SQL using all the memory which is allocated to it.

GilaMonster, I am not 100% sure if it's only memory related, however, I am stuck as to what's the next step....not an exper on performance tuning.

Grant Fritchey, I did select * from sys.dm_os_wait_stats, now which column should I focus.

I really appreciate all of you for giving me valid inputs as to where/what should I be checking. Could this be a CPU issue as well?

Thanks,
SueTons.




Connections to the database take resources and do consume memory. That added to the waits that Grant asked about would help to understand memory pressure.

Did you check with your users to find out where the app is slow?




Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server


SQL RNNR

Posting Performance Based Questions - Gail Shaw
Posting Data Etiquette - Jeff Moden
Hidden RBAR - Jeff Moden
VLFs and the Tran Log - Kimberly Tripp
Post #1403289
Posted Saturday, January 05, 2013 4:04 PM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, February 24, 2014 1:04 PM
Points: 383, Visits: 2,351
[/quote]
Connections to the database take resources and do consume memory. That added to the waits that Grant asked about would help to understand memory pressure.

Did you check with your users to find out where the app is slow?[/quote]

We only found active 50 connections....which is not much. In additions to SQL using all the memory, we are also getting some error as below.

'A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified) ", and also error 40 displayed in certain web application.'

However, this is only happening occasionally and everything else looks fine from the database end.

SueTons.



Regards,
SQLisAwe5oMe.
Post #1403291
Posted Sunday, January 06, 2013 4:06 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 4:48 AM
Points: 14,802, Visits: 27,278
When looking at the wait stats, order them by the total wait time and you can see what is causing things to slow down. This is a simple version of the query:
SELECT TOP (10)
*
FROM sys.dm_os_wait_stats AS dows
ORDER BY wait_time_ms DESC;

The wait types themselves are not self-explanatory (although some are). You'll have to look them up to understand what's causing things to slow down on your system.

Also, if you really are focused on memory, you can use sys.dm_os_ring_buffers to check for specific out of memory messages. I wrote up a method for doing that in an article on Simple-Talk.


----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #1403319
Posted Sunday, January 06, 2013 6:53 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Friday, March 14, 2014 2:19 AM
Points: 2,820, Visits: 3,916
I wil favor here to set the profiler trace (
beware of filters and required columns
), see if you catch there something.


-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done
Post #1403329
Posted Sunday, January 06, 2013 4:30 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 10:06 PM
Points: 35,978, Visits: 30,269
I've been going through this a lot lately and thought I'd share just in case. I don't (yet, but I will) know all the details because the Infrastructure Team owns the resources and "the problem". They have a DR site setup and they use some sort of SAN based replication to keep them in sync. It apparently has some sort of a log (file) and replicates things asynchronusly through the log as a buffer. Everything works great and fast except if the log gets too far behind (typical because of nightly jobs) and the replication goes into what is known as the "synchronus" mode. When it does that, not only do things have to commit on the local server but they also have to commit on the remote server. The connections to the remote server will always be slower than the internal fiber connections we have to the SAN and form the bottle neck. Considering that the system is already way behind when it goes into the synchronuns mode, you can just imagine how slow that makes things.

I'm definitely not sure if this has anything to do with your problem at all or not but you can bet my current problem doesn't show up as a "DR Replication Problem" through the system DMVs. If you have a similar thing going on, the answer won't be obvious either. Check everything and expect the unexpected.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

"Change is inevitable. Change for the better is not." -- 04 August 2013
(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1403372
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse