You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a multi-tenant db model. Each user has a different connection string.
We have a base class that creates the connections and data accessors.
Something like this:
This is our invocation
This is our gcdump
This is our Memory Graph
Further technical details
Microsoft.Data.SqlClient version: 5.2.0
.NET target: net 6
SQL Server version: Azure sql database Level compatibility 160 Version 16
Operating system: Docker
Additional context
We've already conducted tests with pooling set to both true and false, and the problem persists.
Our connection string looks like this:
server={0};uid={1};pwd={2};database={3};connection timeout=5;pooling=true;Max Pool Size=100;Workstation ID=Microservices;Connection Lifetime=60;Application Name=ms-memory;
At night, when traffic is zero, the memory does not decrease.
We also tried calling the garbage collector (GC) manually, and the memory decreased by a few MB.
The text was updated successfully, but these errors were encountered:
Hi ! We found something. We are calling SqlConnection.ClearPool() after each query and the memory leak disappear. However the performance increase a lot !
I was wondering 🤔 Is there a way to have the same pool for diferente connections? Do you know? @DavoudEshtehari
Describe the bug
Hi !
We have a multi-tenant db model. Each user has a different connection string.
We have a base class that creates the connections and data accessors.
Something like this:
Further technical details
Microsoft.Data.SqlClient version: 5.2.0
.NET target: net 6
SQL Server version: Azure sql database Level compatibility 160 Version 16
Operating system: Docker
Additional context
We've already conducted tests with pooling set to both true and false, and the problem persists.
Our connection string looks like this:
At night, when traffic is zero, the memory does not decrease.
We also tried calling the garbage collector (GC) manually, and the memory decreased by a few MB.
The text was updated successfully, but these errors were encountered: