Comments on: Killing the “SQL Server is a Memory Hog” Myth https://thomaslarock.com/2017/08/killing-sql-server-memory-hog-myth/ Thomas LaRock is an author, speaker, data expert, and SQLRockstar. He helps people connect, learn, and share. Along the way he solves data problems, too. Wed, 09 May 2018 16:31:37 +0000 hourly 1 https://wordpress.org/?v=6.7.2 By: Thomas LaRock https://thomaslarock.com/2017/08/killing-sql-server-memory-hog-myth/#comment-21407 Wed, 09 May 2018 16:30:33 +0000 https://thomaslarock.com/?p=18001#comment-21407 David,

The first thing you need to do is find out what the queries are waiting for. In your case, you may be seeing a symptom of the application reading more data pages into memory than necessary due to poor indexing choices, index fragmentation, or even outdated statistics. These items cause SQL to read more pages than necessary, filling up the memory. You will want to examine the wait events for the queries to determine what they are waiting for. If you see a lot of PAGEIOLATCH then you will want to take a look at the queries and their execution plans to isolate the biggest consumers of database pages.

SQL Server will not go outside of the max memory setting for database pages. If you set it to 18GB, it will be close to that 18GB, with some extra possible because the max memory setting doesn’t include all memory regions. So it’s possible to see a number higher than 18GB, but not by much.

HTH

]]> By: David Chaffee https://thomaslarock.com/2017/08/killing-sql-server-memory-hog-myth/#comment-21400 Wed, 09 May 2018 15:07:48 +0000 https://thomaslarock.com/?p=18001#comment-21400 I am VERY new to MSSQL but have been around computers for many years. The problem that I am experiencing with one of my clients is that the the application that utilizes MSSQL gets extremely slow at which point I have to reboot the server. I have 24GB of RAM on an Win 2016 Server. When I check total RAM, I am usually down to about 400 MB of free RAM. My confusion is this – If I reset the total amount of RAM that MSSQL can use to say 18GB, wouldn’t it just hit that 18GB wall and start running slow again?

My BEST GUESS is that the software that uses MSSQL is not written properly to send a command to MSSQL to release the cache once it is finished using the data it has called. Therefor, MSSQL will just hit a lower “brick wall” and then start getting sluggish again. Am I wrong? Or will MSSQL go out to the free RAM, use what it needs and then release that amount of memory in order to get down to the Maximum memory levels that are set in the properties?

]]> By: ThomasLaRock https://thomaslarock.com/2017/08/killing-sql-server-memory-hog-myth/#comment-16101 Mon, 21 Aug 2017 22:51:00 +0000 https://thomaslarock.com/?p=18001#comment-16101 In reply to JD.

No, you need more information than just the PLE counter to determine if more memory is needed.

]]> By: JD https://thomaslarock.com/2017/08/killing-sql-server-memory-hog-myth/#comment-16100 Sat, 19 Aug 2017 23:37:00 +0000 https://thomaslarock.com/?p=18001#comment-16100 Page life expectancy at node level is good enough to see if your SQL Server needs more memory?

]]> By: Scott Brickey https://thomaslarock.com/2017/08/killing-sql-server-memory-hog-myth/#comment-16095 Thu, 17 Aug 2017 17:33:00 +0000 https://thomaslarock.com/?p=18001#comment-16095 It should also be pointed out… WINDOWS (desktop OS) has a similar feature… it will consume memory for caching, on the basis that flushing the memory is an operation that takes all of like two CPU ticks, whereas a cache hit can save thousands of CPU ticks… same concept – memory is cheap to work with, use it for cache whenever possible

]]>