Hello there,
I'm experimenting a bit with Virtuoso as we're trying to figure out if it's a good choice for our Project and while doing some tests I stumbled upon a weird memory usage case.

In this particular case, the Queries I run are:
`DELETE FROM DB.DBA.RDF_QUAD`
`DB.DBA.TTLP_MT (file_to_string_output ('/path/to/ttl_file.ttl'), '', 'http://localhost:8890/XXX')`

The dataset is about 5,7 MB and contains roughly 80k triplets.

Everytime I run the above queries, the RAM usage of Virtuoso increases by about 0,5 MB. Occasionally a few (1-2 MB) get reclaimed, but other than that it keeps increasing.
The test I ran lasted 40 minutes. The queries above were executed at 5sec intervals continuosly and each time the RAM kept increasing by 0,3 - 0,6 MB (mostly 0,5 MB).
Virtuoso started at 99,2 MB and after the first run (delete + import) it increased to 237,1 MB.
After 7:30mins it was sitting at 302 MB.
After 10:50mins it was at 318,2 MB and after 40mins it was above 400MB.

I rebuild Virtuoso with debug symbols so that I could inspect the issue with Valgrind and these are the findings:
> ==471315== LEAK SUMMARY:
> ==471315==    definitely lost: 467,890 bytes in 26,239 blocks
> ==471315==    indirectly lost: 955,209 bytes in 41,848 blocks
> ==471315==      possibly lost: 206,207,327 bytes in 314,533 blocks
> ==471315==    still reachable: 17,579,054 bytes in 131,026 blocks
> ==471315==         suppressed: 0 bytes in 0 blocks`

However, I also run the Valgrind Massif heap profiler, but there it shows constant allocations with occasional spikes which return to normal right after:
![image](https://github.com/openlink/virtuoso-opensource/assets/124195270/15081713-4073-42bd-bf4e-5d09f9abc831)

I'm running the develop/7 branch locally on Ubuntu 20.04.

Configuration is unchanged, running default values.

Any idea what could be the cause? Are there any known issues that have yet to be fixed perhaps?

P.S.: I cannot share the dataset as it's confidential (company stuff).
RAM usage keeps increasing when deleting and reimporting data
This is a GitHub Issue
repo:virtuoso-opensource
owner:openlink
Title : RAM usage keeps increasing when deleting and reimporting data
Issue date:

--- start body ---
Hello there,
I'm experimenting a bit with Virtuoso as we're trying to figure out if it's a good choice for our Project and while doing some tests I stumbled upon a weird memory usage case.

In this particular case, the Queries I run are:
`DELETE FROM DB.DBA.RDF_QUAD`
`DB.DBA.TTLP_MT (file_to_string_output ('/path/to/ttl_file.ttl'), '', 'http://localhost:8890/XXX')`

The dataset is about 5,7 MB and contains roughly 80k triplets.

Everytime I run the above queries, the RAM usage of Virtuoso increases by about 0,5 MB. Occasionally a few (1-2 MB) get reclaimed, but other than that it keeps increasing.
The test I ran lasted 40 minutes. The queries above were executed at 5sec intervals continuosly and each time the RAM kept increasing by 0,3 - 0,6 MB (mostly 0,5 MB).
Virtuoso started at 99,2 MB and after the first run (delete + import) it increased to 237,1 MB.
After 7:30mins it was sitting at 302 MB.
After 10:50mins it was at 318,2 MB and after 40mins it was above 400MB.

I rebuild Virtuoso with debug symbols so that I could inspect the issue with Valgrind and these are the findings:
> ==471315== LEAK SUMMARY:
> ==471315==    definitely lost: 467,890 bytes in 26,239 blocks
> ==471315==    indirectly lost: 955,209 bytes in 41,848 blocks
> ==471315==      possibly lost: 206,207,327 bytes in 314,533 blocks
> ==471315==    still reachable: 17,579,054 bytes in 131,026 blocks
> ==471315==         suppressed: 0 bytes in 0 blocks`

However, I also run the Valgrind Massif heap profiler, but there it shows constant allocations with occasional spikes which return to normal right after:
![image](https://github.com/openlink/virtuoso-opensource/assets/124195270/15081713-4073-42bd-bf4e-5d09f9abc831)

I'm running the develop/7 branch locally on Ubuntu 20.04.

Configuration is unchanged, running default values.

Any idea what could be the cause? Are there any known issues that have yet to be fixed perhaps?

P.S.: I cannot share the dataset as it's confidential (company stuff).
--- end body ---
