Version ghost records in particular are 'soft deleted' rows kept around because some currently executing statement or a long-running open transaction might need that version of the row to produce the correct results.
If you are lucky, this means that someone has left a transaction open for a long time that is (a) using a row versioning transaction isolation level like Read Committed Snapshot Isolation (RCSI) or Snapshot Isolation (SI); and (b) that transaction has accessed user data in the database.
A quick way to see if there are any open transactions is to run DBCC OPENTRAN;. Resolving that transaction will allow the ghost cleanup process to start to catch up.
SQL Server 2022 has an improvement for ghost cleanup so RCSI (statement-level snapshot) transactions can be cleaned up when the statement completes (not waiting for the transaction to end). Since you're not running SQL Server 2022, you're stuck with the old behaviour.
If you are unlucky, you have a Database Availability Group (AG) and there is either some problem with a replica, or there is a long running transaction on one of the replicas.
Queries on replicas always run under Snapshot Isolation, regardless of the isolation level requested. A long-running transaction on a replica might need old row versions to deliver correct results. Since the primary is an exact copy of the replicas, it cannot clean up old ghost versions until every replica has indicated no current transaction could possibly need that data.
You can see if a replica is holding up version ghost cleanup by querying the low_water_mark_for_ghosts column of sys.dm_hadr_database_replica_states. If that column isn't changing over the course of 30s or so, you almost certainly have a long-running replica transaction or some other problem with the replica(s) that is preventing ghost cleanup from making progress.
In the happy scenario, you will find a long-running transaction on a replica and resolve it as for the non-AG case. Otherwise, you have some sort of AG problem that will need expert attention.
There are other scenarios. You might simply have a very large number of databases on the one instance, or a tremendous rate of ghost production due to heavy delete activity (or updates performed by the engine as a delete-insert pair for various reasons, including replication and index key updates).
In other words, the rate of ghost production exceeds the capabilities of the cleanup process. There is not enough information in the question to say whether this applies or not. If other tables and databases on the same instance have deletes but no ghost problem, capacity probably isn't the issue.
