June 14, 2017 at 6:07 am
I am getting this wait type on my DB Server, please let me know the reason y it caused and also the troubleshooting steps
June 14, 2017 at 6:11 am
Are you getting it significantly? All the time, or just occasionally
https://www.sqlskills.com/help/waits/memory_allocation_ext/
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
June 14, 2017 at 6:19 am
Frequently getting this MEMORY ALLOCATION EXT wait type ,which takes upto 40 seconds...which comes with another wait type which is happening frequently PREEMPTIVE_XE_GETTARGETSTATE
June 14, 2017 at 6:35 am
I wouldn't worry about the latter, it's considered a benign wait.
Are you seeing the MEMORY ALLOCATION EXT wait frequently on user sessions? Sessions that are actually running queries ones being run by the application?
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
June 14, 2017 at 6:37 am
Yes i am seeing more often in User session, which the time increases on daily basis
June 14, 2017 at 6:47 am
Are you using filestream?
Are you seeing lots of page splits?
Are you seeing these when inserting or updating LOB data types?
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
June 14, 2017 at 6:54 am
this is the statement
June 14, 2017 at 6:58 am
What monitoring tools are being used for the environment? I've seen this wait type happen frequently with DMV query execution, specifically often with sys.dm_exec_requests, and consider it to be a relatively benign wait type that I filter off as a result. If you have a 3rd party monitoring app that constantly polls the server, this would be a top wait on the instance. Using Activity Monitor in SSMS also polls the DMV's and would see this wait occurring. Paul and I were just discussing this last week when I was working in a client environment and could repeatedly reproduce the wait type occurring for sys.dm_exec_requests and then I could repeat it on my lab VM's so we could get additional call stacks to update the wait information library for this wait type:
https://www.sqlskills.com/help/waits/memory_allocation_ext/
Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
My Blog | Twitter | MVP Profile
Training | Consulting | Become a SQLskills Insider
Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]
June 14, 2017 at 7:02 am
Solarwinds is the tool showing this wait type, anyways to troubleshoot it, please help thanks in advance
June 14, 2017 at 7:29 am
Is it showing that wait type for it's own queries? Why do you think that it needs troubleshooting? Unless something changed with how Solarwinds collects it's data, it's constant polling of the DMV's is the most likely cause of this wait occurring and they haven't updated their app to filter it off like they do other benign waits. Grab the script from this blog post by Paul:
https://www.sqlskills.com/blogs/paul/wait-statistics-or-please-tell-me-where-it-hurts/
and you will see that it is one of the waits that get's filtered off as non-important and benign. Trying to troubleshoot this is chasing your tail, it's not a problem just because Solarwinds is showing it on their dashboard.
Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
My Blog | Twitter | MVP Profile
Training | Consulting | Become a SQLskills Insider
Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]
June 19, 2017 at 7:46 am
As per my understanding from your replies that MEMORY ALLOCATION EXT and PREEMPTIVE_XE_GETTARGETSTATE not going to be the issue, but still not able to understand the root cause for it , please explain more on the DMV's , which is not available much on internet, please help
/* (inserted by DPA)
Character Range: 0 to 272
Waiting on statement:
SELECT target_data
FROM sys.dm_xe_session_targets xet
WITH
(
nolock
)
JOIN sys.dm_xe_sessions xes
WITH
(
nolock
)
ON xes.address = xet.event_session_address
WHERE xes.name = 'telemetry_xevents'
AND xet.target_name = 'ring_buffer'
*/
/* BEGIN ACTIVE SECTION (inserted by DPA) */
SELECT target_data
FROM sys.dm_xe_session_targets xet
WITH
(
nolock
)
JOIN sys.dm_xe_sessions xes
WITH
(
nolock
)
ON xes.address = xet.event_session_address
WHERE xes.name = 'telemetry_xevents'
AND xet.target_name = 'ring_buffer'
/* END ACTIVE SECTION (inserted by DPA) */
June 19, 2017 at 7:59 am
Querying one of the DMVs requires access to resources. Reading the target state for an event session in the case of PREEMPTIVE_XE_GETTARGETSTATE and it's having to wait for that resource. I don't know any other way to explain it. The MEMORY_ALLOCATION_EXT wait is for a preemptive memory allocation during the execution. Every time you query the DMV it needs the resource and will wait to acquire it if it's not available so by the way DPA is designed to query DMVs in an active loop you can expect certain waits to be common that are not a problem or sign of an issue
Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
My Blog | Twitter | MVP Profile
Training | Consulting | Become a SQLskills Insider
Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]
June 19, 2017 at 8:24 am
Any Troubleshooting/resolution which we can apply to this wait types, please help
June 19, 2017 at 8:37 am
GA_SQL - Monday, June 19, 2017 8:24 AMAny Troubleshooting/resolution which we can apply to this wait types, please help
Yes, ignore it.
As Jonathan has pointed out, it comes from acessing DMVs, meaning that monitoring tools (which access DMVs a lot) will incur this wait on their own queries, which means you should ignore it as it's not interesting, it's not hindering your actual application workload.
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
July 28, 2017 at 1:34 pm
I see a lot of waits of the type MEMORY_ALLOCATION_EXT when running DBCC CHECKDB (the lite version, NOINDEX and WITH PHYSICAL_ONLY) on the new database server.
I've tested this VM with PassMark and it shows low memory performance (1300 points against 2300 on my home PC). With simple words, we have enough memory, but it is slow.
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply