memory not releasing

Question

Post reply

memory not releasing

Viewing 6 posts - 16 through 20 (of 20 total)

You must be logged in to reply to this topic. Login to reply

Halcyon Ten Centuries Points: 1331 More actions · Answer 1

regarding memory not releasing, same server build

this is the result of the sys.dm_os_performance_counters

object_nameCounter_namecntr_valuecntr_value_MB

SQLServer:Buffer Manager Database pages 2021281579.000000000

SQLServer:Buffer Manager Free pages 3983593112.000000000

SQLServer:Buffer Manager Stolen pages 20167158.000000000

SQLServer:Buffer Manager Total pages 6206544849.000000000

SQLServer:Memory Manager Target Server Memory (KB) 55744165443.000000000

SQLServer:Memory Manager Total Server Memory (KB) 49652324848.000000000

If I understand it correctly with my number of stolen pages low and a large number of free pages, my sql server is not our of memory and is healthy?

HBhagat Hall of Fame Points: 3341 More actions · Answer 2

Hi Gial,

This is an old post , but this is a problem I am facing now. I have few things what I am not able to configure.

I did read and understand that SQL is build up like this , but how come its behaving differently in different servers.

I have 20 server. There are SQL servers from 2000 to 2008R2. Why I have a problem with the memory in only 1 server? Why this memory problem is not other servers?

After lot of looking into the problem, we found that a few steps in a job is causing the memory increase. But this job was working fine till last thursday, and then suddenly on Friday this started giving a problem. No changes were made in the steps, neither any changes were made in the procedure executed in the steps.

I have decreased the max memory set , but still the problem is there.

What should we do that it does not use all the memory, or how to avoid memory increase.

We have already done 3 reboot of the server to reduce the memory problem.

Please help.

Thanks,

Harsha

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 3

Could you start a new thread for this please. When you do, please give a lot more detail.

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

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

JimRush SSC Journeyman Points: 75 More actions · Answer 4

Typical Microsoft Arrogance....

They assume that they're the only one's using your hardware and consume it all and NEVER relase it. How considerate......

This is insane.... I have a server with 50gig of RAM and SQL server is eating the ENTIRE 50 gig and causing the server to run like a pig.

EVEN THOUGH there is NOTHING go on with the server. This is screwing up monitors and causes our stress testing to fail.

Microsoft is so out of touch and so pathetic... I can't wait for them to go out of business so a customer focused (outside in) company can start producing products that don't hold you and your evnironment hostage.

All hail the Miscrsoft monopoly and dictatorship !!

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 5

JimRush (10/24/2012)
This is insane.... I have a server with 50gig of RAM and SQL server is eating the ENTIRE 50 gig and causing the server to run like a pig.

Because you haven't set max server memory to a value that tells SQL how much memory it is allowed to use.

I've give you something to read up, but from the tone of the post you don't want a solution, just someone to blame.

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

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

lawande.shailendra SSC Journeyman Points: 99 More actions · Answer 6

I am also facing the same issue in SQL Server 2012 and in SQL Server 2008. Query response become very slow when SQL server using maximum memory of the server. Indexes on my database are also proper.