The “transaction aborted” message results from an INI setting being too low for your current bulk-loading activity – but note that the current setting may be appropriate for later ongoing activity. See the manual’s discussion of TransactionAfterImageLimit –
TransactionAfterImageLimit = N Bytes default
50000000. When the roll-forward log entry of a transaction exceeds this size, the transaction is too large and is marked as uncommittable. This work as upper limit otherwise infinite (transactions). The default is 50MB. Also note that transaction roll-back data takes about 2x the space of roll-forward data. Hence when the transaction roll-forward data is 50MB, the total transient consumption is closer to 150 MB.
Deleting data from the DB does not immediately free the disk space previously occupied by that data. Virtuoso has an auto-compaction feature which will eventually free space. New data will be loaded into the space previously occupied by deleted data, but of course this reuse will be imperfect. You may be able to free some space by running a
CHECKPOINT; or the
DB..VACUUM (); procedure (depending on your workflow, it may make sense to run
DB..VACUUM (); twice or three times in a cycle). You can also do a backup-dump-and-reload to immediately reclaim disk – though you must temporarily consume substantially more disk space during this process.
I would encourage you to describe what you’re really trying to achieve – both starting points and desired end results – and to define your terms as you go.
You have expressed a wish to “create 200 objects in Virtuoso for less than 30 ms” (by which I think you mean “≤ 30 ms total to create 200 objects”). However, it is not clear if those “objects” would be triples of a few dozen or hundred bytes each, for which your wish should be easily granted, or if those “objects” are graphs of thousands or millions of triples and multiple GB each, for which your wish might not be so easily granted, if at all, especially if everything is moving over the network and not moving between disk and RAM and disk on a single box…
As is true of all software, the speed of all Virtuoso activity is impacted by infrastructure between action points, and by the resources Virtuoso has to work with on its local host(s). Proper tuning matters a great deal – such as ensuring that Virtuoso knows how much memory it should use for active work, and leaving enough free RAM and disk for task-specific activities.
You might benefit by exploring some of the benchmarks in active use –