January 10, 2025 at 1:10 pm
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
January 20, 2025 at 5:37 am
Like I said on the other thread with the identical name (Note: there is zero need to double post on this forum)...
This sounds like either a "Connection Leak" or a "Memory Leak". A "Connection Leak" is where no connection is ever closed and everyone gets a new connection (which take memory) or a "Memory Leak" where certain types of "Cursors" are simply not being closed and the code keeps opening new ones. It could also be some sort of "in-memory logging" that is never cleared except by a restart.
These types of things are frequently difficult to find but, man... is it ever worth it to find them and fix them.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2025 at 6:13 am
Thanks for your response Jeff. The number of connections is stable. I should have mentioned that we have several of these database servers (1 instance per server) with comparable workload and different SQL versions. On 2019 or 2022 servers the proc cache remains constant. We are planning an upgrade on short term. Until now we might not have noticed it because of the monthly patching we're doing; it takes about a month before we hit critical levels. In December however, we had a freeze and skipped maintenance.
If we see it happening after the upgrade as well, we've got work to do.
February 21, 2025 at 9:53 am
To round up this topic, we upgraded to SQL 2019 and the issue is gone or at least not a problem anymore. There is a bit of a decrease but nowhere near as steep as before.

Viewing 4 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply