July 29, 2008 at 8:52 am
I have collected data from a number of AWE perfmon counters, but I don't know how to interpret the data.
Could someone pls help me find out whether the AWE memory allocated to my server instance is sufficient? (Currently set at 13.2 GB).
Here are the counters:
Buffer Manager\AWE lookup maps/sec (value hovering around 15,000 for over an hour)
Buffer Manager\AWE stolen maps/sec (value hovering around 10,000 during same time span)
Buffer Manager\AWE unmap calls/sec (over 20,000 for sustained period)
Buffer Manager\AWE unmap pages/sec (over 20,000 for sustained period)
Buffer Manager\AWE write maps/sec (frequently exceeding 100 in the course of an hour)
I would provide graphs but don't know how to.
Any ideas pls?
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
July 29, 2008 at 9:09 am
that's really the wrong set of data and question. Why do you think you don't have enough memory?
I'd suggest you start with page life expectancy - this will give a good idea if you have sufficient memory - you can't influence the awe counters and I've never found they are relative to anything.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
July 29, 2008 at 9:26 am
colin Leversuch-Roberts (7/29/2008)
that's really the wrong set of data and question. Why do you think you don't have enough memory?I'd suggest you start with page life expectancy - this will give a good idea if you have sufficient memory - you can't influence the awe counters and I've never found they are relative to anything.
Page life expectancy goes frequently below 200 in the course of an hour. I think that's indicative of memory pressure, correct?
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
July 29, 2008 at 12:06 pm
well I think the official ms figure is 300 although I prefer a higher value. If the page life goes to zero then you're flushing the cache and that is bad.
I did a lot of research on awe memory pressures, looking at page lookups and such and found that the values you might want will vary from one server to another and the limit is hardware dependant, so in other words tricky!! It's easier in 2005 but there are some commands which will show how memory is being used. You might want to check umsstats that can also help.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
July 29, 2008 at 3:21 pm
colin Leversuch-Roberts (7/29/2008)
well I think the official ms figure is 300 although I prefer a higher value. If the page life goes to zero then you're flushing the cache and that is bad.I did a lot of research on awe memory pressures, looking at page lookups and such and found that the values you might want will vary from one server to another and the limit is hardware dependant, so in other words tricky!! It's easier in 2005 but there are some commands which will show how memory is being used. You might want to check umsstats that can also help.
Thank you.
Page life expectancy goes down to 7 at some point. That's the lowest value in my interval. Should I consider expanding AWE utilization from the current value of 13.2 GB?
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
July 30, 2008 at 11:28 am
it's worth seeking out any high io queries, fixing them ( if they exist ) is a much better solution!
Mind it depends upon database size and so on too - I usually use low page life as a sign of memory shortage. Check queries first as you may get some real gains .
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
July 30, 2008 at 11:48 am
colin Leversuch-Roberts (7/30/2008)
it's worth seeking out any high io queries, fixing them ( if they exist ) is a much better solution!Mind it depends upon database size and so on too - I usually use low page life as a sign of memory shortage. Check queries first as you may get some real gains .
Thanks, will do.
There is a lot of room for tuning in our environment, large table scans etc.
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply