January 3, 2013 at 8:17 pm
All,
We have some performance issue..SQL server is running very slow due to high memory usage..this is a 2 node active/passive cluster. Only 1 instance is running, no other apps.
Total 56GB RAM and 46GB is allocated SQL. No blocking, no open transactions, no long running queries found.
Is there any other way to release the memory? Or how can we find why SQL server is using high memory?
What are some of the causes of using high memory? Someone with experience in performance tuning, please advise.
Thanks,
SueTons
Regards,
SQLisAwe5oMe.
January 3, 2013 at 10:09 pm
How many connections? Do you have a high volume of transactions or jobs running currently?
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
January 4, 2013 at 12:30 am
Can you elaborate on what you mean by SQL is running slow? Specifics? You state that it is slow but there are no long running queries found.
Joie Andrew
"Since 1982"
January 4, 2013 at 2:24 am
SQLCrazyCertified (1/3/2013)
We have some performance issue..SQL server is running very slow due to high memory usage.
Are you sure that high memory usage is causing SQL to run slow? Cause, not correlation?
Is there any other way to release the memory? Or how can we find why SQL server is using high memory?
What are some of the causes of using high memory? Someone with experience in performance tuning, please advise.
Normal, expected behaviour. SQL uses as much memory as it is allowed to use to cache data and plans to avoid slow disk access and expensive plan recompilations. SQL will use up to the max it is allowed and that is perfectly fine. You typically want SQL to use lots of memory as it allows for efficient caching.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 4, 2013 at 4:15 am
What are your top 5 wait stats from sys.dm_os_wait_stats? If they are not memory related, then I doubt memory is the cause of the slow performance.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 4, 2013 at 9:11 am
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.
Regards,
SQLisAwe5oMe.
January 4, 2013 at 9:24 am
It could be anything. Shotgun tuning however won't help.
Chapter 1: http://www.simple-talk.com/books/sql-books/troubleshooting-sql-server-a-guide-for-the-accidental-dba/ Identify the problem, then consider what the potential solution is.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 4, 2013 at 6:33 pm
Is there any other way to release the memory? Or how can we find why SQL server is using high memory?
What are some of the causes of using high memory? Someone with experience in performance tuning, please advise.
Normal, expected behaviour. SQL uses as much memory as it is allowed to use to cache data and plans to avoid slow disk access and expensive plan recompilations. SQL will use up to the max it is allowed and that is perfectly fine. You typically want SQL to use lots of memory as it allows for efficient caching.
[/quote]
Gail,
You mentioned that SQL using all of it's memory which is allocated to it is a normal behavior, if this is true, when does the SQL release the memory?
I know it won't release the memory to OS, but when does SQL gets more memory to do other work/processes. Please advise.
SueTons.
Regards,
SQLisAwe5oMe.
January 5, 2013 at 1:46 am
SQLCrazyCertified (1/4/2013)
You mentioned that SQL using all of it's memory which is allocated to it is a normal behavior, if this is true, when does the SQL release the memory?
When the OS signals that it's under memory pressure or when SQL shuts down.
I know it won't release the memory to OS, but when does SQL gets more memory to do other work/processes. Please advise.
Get more memory? If it's allocated up to max server memory then it won't allocate more.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 5, 2013 at 12:50 pm
GilaMonster (1/5/2013)
SQLCrazyCertified (1/4/2013)
You mentioned that SQL using all of it's memory which is allocated to it is a normal behavior, if this is true, when does the SQL release the memory?When the OS signals that it's under memory pressure or when SQL shuts down.
I know it won't release the memory to OS, but when does SQL gets more memory to do other work/processes. Please advise.
Get more memory? If it's allocated up to max server memory then it won't allocate more.
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, so, in this scenario can we say that memory is the issue for performance issues? If that's the case how can you say it's the normal expected behavior?
SueTons.
Regards,
SQLisAwe5oMe.
January 5, 2013 at 3:22 pm
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, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 5, 2013 at 3:29 pm
Ok. Thank you. I will read further.
SueTons.
Regards,
SQLisAwe5oMe.
January 5, 2013 at 3:55 pm
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, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
January 5, 2013 at 4:04 pm
[/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.
January 6, 2013 at 4:06 am
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)
*
FROMsys.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[/url].
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply