Sergey Odinokov

Thanks for reporting this. Do you see any exceptions [logged](https://docs.hangfire.io/en/latest/configuration/configuring-logging.html)? May be there was another problem that lead to full stop of query processor.

Please try to use Microsoft.Data.SqlClient package of the latest version instead as shown here – https://github.com/HangfireIO/Hangfire/issues/1735#issuecomment-831913142. There are strange problems with connections in System.Data.SqlClient that's solved by using MD.SqlClient, and...

All the recent problems with SQL Server were fixed by using that new package, some reported to support, and one of them is #2065. So there's a high chance this...

Sometimes it depends on the storage implementation, and problems with job storage implementation might cause this problem to happen. Could you tell me what storage you are using? Also, it's...

Yes, I see SDK 4.5 is missing on that page, thanks for letting know. I will dump support to 4.5.1 in 1.8.0 release, but know currently when it will be...

Yes, high number of ghost rows is likely the reason for the high CPU usage. Due to the nature of the Dequeue method that's based on a relational table, rows...

I tried to search the internet for "version ghost record count" and found this article – https://techcommunity.microsoft.com/t5/sql-server-support-blog/query-performance-drops-due-to-version-ghost-record-count-in/ba-p/3425900. Could you tell me whether you are using AlwaysOn setup?

High number of "version ghost record" is the main symptom, I believe. They can also come from snapshot isolation. Did you enable it for your database or using read committed...

Found also this one with some links https://michaeljswart.com/2017/08/problem-with-too-many-version_ghost_records/

SCAN operator that's used for that query, that's required by the nature of the job queue, in SQL Server acquires row lock for each of those ghost rows each time...