SQL Server is using a lot more RAM than it should

I have a SQL Server 2012 instance using more RAM that it should.

The SQL Server process is using about 22.5GB RAM:

The instance is configured to use a maximum of 10GB:

Which is way more then expected. (It will lead to a server crash and we will have to reboot to get it back).

I checked the memory usage (clerks) with this query:

select type, name, pages_kb/1024.0/1024.0 "size Gb" from sys.dm_os_memory_clerks
order by pages_kb desc

SQL Server only seem to see about 7GB RAM being used:

I know it's an old version of SQL Server (and it's not patched to the latest sadly) but I wasn't able to find any clear documentation regarding a memory leak in SQL Server 2012 SP2.

Where should I look to find why SQL Server is using about 200% what it should?

There is a linked server on this instance. A lot using SQL drivers (SQLNCLI and SQLNCLI11) but there is also some using a "PC SOFT OLE DB provider for HFSQL" which I've never seen before.

Is there any way I could 'prove' this driver is the problem? The client will probably not agree to changing the setup based on an assumption, so if there is any way (other then disabling) to clearly show how much RAM is being used by the linked server, that would be priceless.

@Aleksey: This is what the prod returns

The fact that dm_os_memory_clerks doesn't show the memory strongly suggests that the memory was allocated outside of the SQL Server engine.

"PC SOFT OLE DB provider for HFSQL"

That'll be the culprit. Many 3rd party OleDb providers are not hardened for use in long-lived processes. A small memory leak in a desktop application is rarely even noticeable, so they get through testing without finding the issue.

The best solution here is to move the OleDB driver to a short-lived process like an SSIS package, or PowerShell job or similar. If that's not possible you can try to push the OleDb Provider out-of-process while still using Linked Server, either clearing the "Allow InProcess" flag and doing a bunch of DCOM configuration (see eg Setting up linked servers with an out-of-process OLEDB provider ), or by using the SSIS Data Streaming Destination and replacing the Linked Server with

SELECT * FROM OPENQUERY([Default Linked Server for Integration Services], N'Folder=Power BI;Project=SSISPackagePublishing;Package=Package.dtsx')

The other solution is to bounce SQL Server on a schedule.

Is there any way I could 'prove' this driver is the problem?

There's nothing that tracks native code memory allocations outside of SQL Server's control. The only way I can think to prove it is to hit the linked server repeatedly and see if you can trigger the memory leak.

If you escalate a Support case up far enough, they could probably find the leak definitively.

StackExchange Database Administrators Q#305473, answer score: 11