Version store out of memory (cleanup already attempted) When Calling Save

[ronMilne]

I'm attempting to create a database and import a large amount of records into a single table, after approx 9,500 i get the aforementioned exception? I've taken the StockSample.cs as a starting point.

[michaelthorp]

@ronMilne - The way the underlying database works is that when you want to add/delete stuff the operation gets written to the log and then a task is scheduled with the VersionStore to actually do the work. This is to provide a consistent view to any transactions that may have been opened before this add/delete/modification operation.

One of the most common reasons to run out of VersionStore memory is a long-running transaction. Are you trying to import all records in one transaction or are you batching them? Is any other work happening on this database in the meantime? Could there be a long running transaction in the other work? This pattern, for example, would be problematic:

Thread1: Start transaction, read some data Thread2: Start transaction, import some data, commit transaction Thread2: Start transaction, import some more data, commit transaction Thread2: Start transaction, import some more data, commit transaction Thread2: Start transaction, import some more data, commit transaction Thread1: Commit transaction

All the data imported by Thread2 will remain in the VersionStore until Thread1's transaction commits.

Alternatively, you might just be running out because of the volume of work you are doing. This is configurable using the InstanceParameters.MaxVerPages parameter. The default for this is, I believe, 64 and each page represents a 64k chunk of memory. So you could experiment with increasing this. It's a bit tricky to dial it in properly, but it is runtime configurable so you could give it a HUGE boost while importing the data, then move it back to a more reasonable value. You can take a look at this TechNet article that talks a bit about how to find a more deterministically sound value for VersionStore size, but it may be overkill to go through all this.

[djbrkns]

@michaelthorp Thank you! Your comment about long running transactions had me look and find that I was conflicting with currently running SQL Agent jobs that were running SSIS packages that were holding open long transactions.

I ran into "Version store out of memory" while attempting to run an Octopus deployment.
In my case, the error appears to have been related to a deployment that attempted to drop or alter an object that was currently in use. My deployment worked after the SQL Agent job completed and / or I safely canceled the job(s). The error was a little deceptive. In my case, my deployment appears to have been colliding with already running processes, locked tables, and it wasn't my deployment that was trying to do too much.