Closed KonradHoeffner closed 3 years ago
Found the probably source by executing the same query in the conductor, which includes graphs that aren't publicly available. The culprit seems to be http://dbpedia.org with 12571356 triples
No. of rows in result: 26
Deleted the graph.
The file is still 3.6 GB uncompressed in size. Restarting.
Restarting didn't help, I will wait a few days to see if it cleans the cache, or whatever reserves the memory, on its own.
I stopped the daily backup of the SNIK toolset until further notice. The monthly backup will continue to be performed and must be monitored in terms of size.
I got an answer in https://stackoverflow.com/questions/66692432/how-to-shrink-virtuoso-db-file-size-after-deleting-a-large-graph/66700096#66700096:
Go to the conductor and in Database -> Interactive SQL enter DB.DBA.vacuum ();
.
It increased to 4.7 GB now but I expect that to drop.
The only way I was able to fix this was:
dump_graphs();
and call it to save all graphs in the 'dumps' folder as graph...
clean-logs.sh
load_graphs('dumps/all');
@SebStaeubert: You can enable the daily backups again.
Now the OntoWiki does not work correctly anymore, however.
@SebStaeubert: You can enable the daily backups again.
Backup is enabled again.
Now the whole server is not reachable anymore over HTTP (SSH works but not the web pages). But I suspect that has other reasons as other web internal pages also don't work anymore at the moment.
@SebStaeubert: You can enable the daily backups again.
Backup is enabled again.
I noticed that the dumps
subdirectory of data is backed up as well, which add backups inside backups. Can we ignore this directory for this type of backup?
The reason for the service disruption only occurred on my machine and was caused by my network address being mistakenly blacklisted. This has since been fixed and the backup is now smaller, so this issue is finished.
Something happened between July 1 and August 1 2020:
However we don't have that many triples:
Execute