As discussed in our post "Pruning old backups", --prune is by far the most resource intensive operation that you can perform with (c)XSIBackup-DC.
(c)XSIBackup-DC still depends on the sort binary, present in (c)ESXi and most Linux systems to sort the block lists. We will improve that in the next main releases, hopefully 184.108.40.206 will include a totally C native sorting mechanism.
If you try now to prune a huge repository, holding millions of blocks, you will sometimes receive an "out of memory" error from part of sort and the prune operation will fail. If your repos are smaller everything will work fine, nonetheless it's not possible to know that on advance.
If you want to keep huge repos and your server is short of resources, you should try to just rotate your repositories. Per instance, keep two repositories on alternate days, then once a certain volume of data has been reached, just rename one of the repos and let the job create a new one. After a few days you can just delete the old.
Proceed the same way every 'n' days such that you always keep the number of restore points that you want to keep.
Another aproach consists in keeping a fixed number of snapshots per VM. This is interesting in case your production VMs don't have to support a big fragmented load while they are on production, like in the case of web or DB servers. This will unfold as many inner restore points as snapshots are kept.
We have created SNRoll to help you automate keeping a fixed number of snapshots in a given VM.