May 12, 2005 at 2:14 am
Ah ok, that explains it.
Well, like you might have noticed in DBCC MEMORYSTATUS second section you can see the minimum number of pages that the lazywriter tries to keep in the free list. Also, I did a little research and found the probable answer to your original question (why the cache continues to grow and then when it's filled up you start sseeing a performance hit).
When the number of free pages falls below the minimum level, the lazywriter tries to create more free pages. In normal operation this means that it will flush pages to disk so that they can be reused, in other words they are moved to the free list. However when the memory that SQL Server uses have not yet reached the target max memory lazywriter will not flush any existing pages. Instead it will only commit more memory to the buffer cache, therybe increasing the size of the cache and especially the number of free pages.
So, now, am I right in assuming that you have determined that there is not really a problem with your system?
May 12, 2005 at 3:42 am
Yes Chris, you are. The lazywriter starts to do his job (clean inactive pages) when the SQL server takes the maximum possible memory and there are no free buffer cache pages anymore or something like that. In our situation SQL takes only half (1.6GB) of possible 3GB. So therefore the lazywriter keeps sleeping
Thanks again for your patient and for the help
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply