CPU performances Openlink virtuoso

Hi everyone,

We are experiencing performance issues on a two-node Virtuoso cluster. We use the free version. In the logs, we repeatedly see the following warning:

WARNING: * Monitor: System is under high load. Adding cluster nodes or using more replicated copies may be needed

At the same time, the CPU on one of the nodes spikes close to 100%, and the system becomes very slow.

Some details about our nodes:

RAM: 32 GB per node

CPU: 16 cores per node

Two-node cluster, default Virtuoso configuration

Our impression is that the issue may not be related to RAM availability, but rather to inefficient memory usage by Virtuoso, since CPU usage becomes critical even though there is still free memory.

We would like to understand:

  • If anyone has experienced the same warning and what strategies helped.

  • How to optimize memory usage in Virtuoso to reduce CPU load.

  • Whether it is recommended to add more nodes or adjust data replication to better balance the load?

I found out that in virtuoso.ini we have these value

ThreadsPerQuery = 4
NumberOfBuffers = 680000
MaxDirtyBuffers = 500000

considering this info for the first node:

bin/isql
OpenLink Virtuoso Interactive SQL (Virtuoso) Version 07.20.3238 as of Jul 25 2024 Type HELP; for help and EXIT; to exit.
SQL> status();
Connected to OpenLink Virtuoso
Driver: 07.20.3238 OpenLink Virtuoso ODBC Driver REPORT VARCHAR _______________________________________________________________________________
OpenLink Virtuoso  Server
Version 07.20.3238-pthreads for Linux as of Jul 25 2024 (d89671fa1) Started on: 2025-09-25 23:39 GMT+2
CPU: 662.58% RSS: 6599MB
Database Status:
  File size 2499805184, 5548032 pages, 1592862 free.
  680000 buffers, 292904 used, 3 dirty 18 wired down, repl age 0 0 w. io 7 w/crsr.
  Disk Usage: 293390 reads avg 0 msec, 0% r 0% w last  0 s, 3367 writes flush          0 MB/s,
    1278 read ahead, batch = 224.  Autocompact 0 in 0 out, 0% saved.
Gate:  2166 2nd in reads, 0 gate write waits, 0 in while read 0 busy scrap.
Log = /data/usr/local/var/lib/virtuoso/db/virtuoso.trx, 1254 bytes
616725 pages have been changed since last backup (in checkpoint state) Current backup prefix: backup_# Current backup timestamp: 0x6E24-0x72-0xB2 Last backup date: Thu Jul 25 11:31:03 2024
Clients: 1 connects, max 1 concurrent
RPC: 4 calls, 1 pending, 1 max until now, 0 queued, 0 burst reads (0%), 0 second 40M large, 120M max Checkpoint Remap 0 pages, 0 mapped back. 1 s atomic time.
    DB master 5548032 total 1592862 free 0 remap 0 mapped back
   temp  1536 total 1531 free
Lock Status: 0 deadlocks of which 0 2r1w, 0 waits,
   Currently 10 threads running 0 threads waiting 0 threads in vdb.
Pending:
Client 1111:1:  Account: dba, 203 bytes in, 286 bytes out, 1 stmts.
PID: 5675, OS: unix, Application: unknown, IP#: 127.0.0.1 Transaction status: PENDING, 1 threads.
Locks:

Running Statements:
 Time (msec) Text
         124 status()

Hash indexes

40 Rows. -- 125 msec.

And this for the second node:

bin/isql
OpenLink Virtuoso Interactive SQL (Virtuoso)
Version 07.20.3238 as of Jul 25 2024
Type HELP; for help and EXIT; to exit.
SQL> status();
Connected to OpenLink Virtuoso
Driver: 07.20.3238 OpenLink Virtuoso ODBC Driver
REPORT
VARCHAR
_______________________________________________________________________________
OpenLink Virtuoso Server
Version 07.20.3238-pthreads for Linux as of Jul 25 2024 (d89671fa1)
Started on: 2025-09-24 17:16 GMT+2
CPU: 1108.64% RSS: 6481MB
Database Status:
File size 2510290944, 5549312 pages, 1604217 free.
680000 buffers, 287495 used, 3 dirty 22 wired down, repl age 0 0 w. io 9 w/crsr.
Disk Usage: 288203 reads avg 0 msec, 0% r 0% w last 0 s, 8237 writes flush 8.772 MB/s,
1243 read ahead, batch = 227. Autocompact 0 in 0 out, 0% saved.
Gate: 1321 2nd in reads, 0 gate write waits, 0 in while read 0 busy scrap.
Log = /data/usr/local/var/lib/virtuoso/db/virtuoso.trx, 3564 bytes
609108 pages have been changed since last backup (in checkpoint state)
Current backup prefix: backup_#
Current backup timestamp: 0x273A-0x1F-0xF6
Last backup date: Thu Jul 25 12:00:20 2024
Clients: 1 connects, max 1 concurrent
RPC: 4 calls, 1 pending, 1 max until now, 0 queued, 0 burst reads (0%), 0 second 52M large, 118M max
Checkpoint Remap 19 pages, 0 mapped back. 4 s atomic time.
DB master 5549312 total 1604217 free 19 remap 0 mapped back
temp 6656 total 6651 free
Lock Status: 0 deadlocks of which 0 2r1w, 0 waits,
Currently 10 threads running 0 threads waiting 0 threads in vdb.
Pending:
Client 1111:1: Account: dba, 203 bytes in, 286 bytes out, 1 stmts.
PID: 32022, OS: unix, Application: unknown, IP#: 127.0.0.1
Transaction status: PENDING, 1 threads.
Locks:

Running Statements:
Time (msec) Text
121 status()

Hash indexes

40 Rows. -- 122 msec.

How can I fix this situtation?

Any suggestions are very welcome.

Thank you

  • List item

What do you mean by a two-node Virtuoso cluster, as using the Virtuoso open source product which does not support Virtuoso scale out or RDF Replication Clustering ? I assume you have two Virtuoso open source servers which are kept in-sync by some method you have devised ?

Have you run a database integrity check to determine if there is any corruption in the database, with the command:

backup '/dev/null';

and check the primary key on the RDF_QUAD table is not broken by running the command:

select count (s), count (p ), count (o ), count (g ) from rdf_quad   table option (index rdf_quad, check);

The counts of the s, p, o, g columns should all be the same

Check the RDF Index counts with the queries:

select count (*) from rdf_quad a table option (index rdf_quad) where not exists (select 1 from rdf_quad b table option (loop, index rdf_quad_pogs) where a.g = b.g and a.p = b.p and a.o = b.o and a.s = b.s); 
select count (*) from rdf_quad a table option (index rdf_quad_pogs) where not exists (select 1 from rdf_quad b table option (loop, index primary key) where a.g = b.g and a.p = b.p and a.o = b.o and a.s = b.s); 
select count (*) from rdf_quad a table option (index rdf_quad_pogs) where not exists (select 1 from rdf_quad b table option (loop, index rdf_quad_op) where a.g = b.g and a.p = b.p and a.o = b.o and a.s = b.s); 
select count (*) from rdf_quad a table option (index rdf_quad_pogs) where not exists (select 1 from rdf_quad b table option (loop, index rdf_quad_sp) where a.g = b.g and a.p = b.p and a.o = b.o and a.s = b.s); 
select count (*) from rdf_quad a table option (index rdf_quad_pogs) where not exists (select 1 from rdf_quad b table option (loop, index rdf_quad_gs) where a.g = b.g and a.p = b.p and a.o = b.o and a.s = b.s);

If any counts are not 0 it indicates a bad index.

What is the current triple count and typical query work load against these Virtuoso servers ?

Virtuoso query logging can also be enabled to help see where the processing time is being spent causing the high CPU consumption.

Or i need to focus also to other parameters? Thank you in advance

Hello, yes the two node are kept in-sync by our policy implemented. I’m seeing about query logging and database integrity check and I’ll try it, thank you.

I want to add that this is the virtuoso.ini of the node having cpu problems


;
;  virtuoso.ini
;
;  Configuration file for the OpenLink Virtuoso VDBMS Server
;
;  To learn more about this product, or any other product in our
;  portfolio, please check out our web site at:
;
;      http://virtuoso.openlinksw.com/
;
;  or contact us at:
;
;      general.information@openlinksw.com
;
;  If you have any technical questions, please contact our support
;  staff at:
;
;      technical.support@openlinksw.com
;
;
;  Database setup
;
[Database]
DatabaseFile       = /data/usr/local/var/lib/virtuoso/db/virtuoso.db
ErrorLogFile       = /data/usr/local/var/lib/virtuoso/db/virtuoso.log
LockFile           = /data/usr/local/var/lib/virtuoso/db/virtuoso.lck
TransactionFile    = /data/usr/local/var/lib/virtuoso/db/virtuoso.trx
xa_persistent_file = /data/usr/local/var/lib/virtuoso/db/virtuoso.pxa
ErrorLogLevel      = 7
FileExtend         = 200
MaxCheckpointRemap = 2000
Striping           = 0
TempStorage        = TempDatabase

[TempDatabase]
DatabaseFile       = /data/usr/local/var/lib/virtuoso/db/virtuoso-temp.db
TransactionFile    = /data/usr/local/var/lib/virtuoso/db/virtuoso-temp.trx
MaxCheckpointRemap = 2000
Striping           = 0

;
;  Server parameters
;
[Parameters]
ServerPort               = 1111
LiteMode                 = 0
DisableUnixSocket        = 1
DisableTcpSocket         = 0
;SSLServerPort			= 2111
;SSLCertificate			= cert.pem
;SSLPrivateKey			= pk.pem
;X509ClientVerify		= 0
;X509ClientVerifyDepth		= 0
;X509ClientVerifyCAFile		= ca.pem
MaxClientConnections     = 20
CheckpointInterval       = 120
O_DIRECT                 = 0
CaseMode                 = 2
MaxStaticCursorRows      = 5000
CheckpointAuditTrail     = 0
AllowOSCalls             = 0
SchedulerInterval        = 10
DirsAllowed              = ., /data/usr/local/share/virtuoso/vad
ThreadCleanupInterval    = 0
ThreadThreshold          = 10
ResourcesCleanupInterval = 0
FreeTextBatchSize        = 100000
SingleCPU                = 0
VADInstallDir            = /data/usr/local/share/virtuoso/vad/
PrefixResultNames        = 0
RdfFreeTextRulesSize     = 100
IndexTreeMaps            = 256
MaxMemPoolSize           = 200000000
PrefixResultNames        = 0
MacSpotlight             = 0
IndexTreeMaps            = 64
MaxQueryMem              = 5G	; memory allocated to query processor
VectorSize               = 1000	; initial parallel query vector (array of query operations) size
MaxVectorSize            = 1000000	; query vector size threshold.
AdjustVectorSize         = 0
ThreadsPerQuery          = 4
AsyncQueueMaxThreads     = 10
;;
;; When running with large data sets, one should configure the Virtuoso
;; process to use between 2/3 to 3/5 of free system memory and to stripe
;; storage on all available disks.
;;
;; Uncomment next two lines if there is 2 GB system memory free
;NumberOfBuffers          = 170000
;MaxDirtyBuffers          = 130000
;; Uncomment next two lines if there is 4 GB system memory free
;NumberOfBuffers          = 340000
; MaxDirtyBuffers          = 250000
;; Uncomment next two lines if there is 8 GB system memory free
;NumberOfBuffers          = 680000
;MaxDirtyBuffers          = 500000
;; Uncomment next two lines if there is 16 GB system memory free
;NumberOfBuffers          = 1360000
;MaxDirtyBuffers          = 1000000
;; Uncomment next two lines if there is 32 GB system memory free
;NumberOfBuffers          = 2720000
;MaxDirtyBuffers          = 2000000
;; Uncomment next two lines if there is 48 GB system memory free
;NumberOfBuffers          = 4000000
;MaxDirtyBuffers          = 3000000
;; Uncomment next two lines if there is 64 GB system memory free
;NumberOfBuffers          = 5450000
;MaxDirtyBuffers          = 4000000
;;
;; Note the default settings will take very little memory
;; but will not result in very good performance
;;
NumberOfBuffers          = 680000
MaxDirtyBuffers          = 500000

[HTTPServer]
ServerPort                  = 8890
ServerRoot                  = /data/usr/local/var/lib/virtuoso/vsp
MaxClientConnections        = 10
DavRoot                     = DAV
EnabledDavVSP               = 0
HTTPProxyEnabled            = 0
TempASPXDir                 = 0
DefaultMailServer           = localhost:25
ServerThreads               = 100
MaxKeepAlives               = 10
KeepAliveTimeout            = 10
MaxCachedProxyConnections   = 10
ProxyConnectionCacheTimeout = 15
HTTPThreadSize              = 280000
HttpPrintWarningsInOutput   = 0
Charset                     = UTF-8
;HTTPLogFile                 = /data/usr/local/var/lib/virtuoso/db/http29082018.log
MaintenancePage             = atomic.html
EnabledGzipContent          = 1

[AutoRepair]
BadParentLinks = 0

[Client]
SQL_PREFETCH_ROWS  = 100
SQL_PREFETCH_BYTES = 16000
SQL_QUERY_TIMEOUT  = 0
SQL_TXN_TIMEOUT    = 0
;SQL_NO_CHAR_C_ESCAPE		= 1
;SQL_UTF8_EXECS			= 0
;SQL_NO_SYSTEM_TABLES		= 0
;SQL_BINARY_TIMESTAMP		= 1
;SQL_ENCRYPTION_ON_PASSWORD	= -1

[VDB]
ArrayOptimization           = 0
NumArrayParameters          = 10
VDBDisconnectTimeout        = 1000
KeepConnectionOnFixedThread = 0

[Replication]
ServerName   = db-C1O-EIM-ODP01
ServerEnable = 1
QueueMax     = 50000

;
;  Striping setup
;
;  These parameters have only effect when Striping is set to 1 in the
;  [Database] section, in which case the DatabaseFile parameter is ignored.
;
;  With striping, the database is spawned across multiple segments
;  where each segment can have multiple stripes.
;
;  Format of the lines below:
;    Segment<number> = <size>, <stripe file name> [, <stripe file name> .. ]
;
;  <number> must be ordered from 1 up.
;
;  The <size> is the total size of the segment which is equally divided
;  across all stripes forming  the segment. Its specification can be in
;  gigabytes (g), megabytes (m), kilobytes (k) or in database blocks
;  (b, the default)
;
;  Note that the segment size must be a multiple of the database page size
;  which is currently 8k. Also, the segment size must be divisible by the
;  number of stripe files forming  the segment.
;
;  The example below creates a 200 meg database striped on two segments
;  with two stripes of 50 meg and one of 100 meg.
;
;  You can always add more segments to the configuration, but once
;  added, do not change the setup.
;
[Striping]
Segment1 = 100M, db-seg1-1.db, db-seg1-2.db
Segment2 = 100M, db-seg2-1.db
;...
;[TempStriping]
;Segment1			= 100M, db-seg1-1.db, db-seg1-2.db
;Segment2			= 100M, db-seg2-1.db
;...
;[Ucms]
;UcmPath			= <path>
;Ucm1				= <file>
;Ucm2				= <file>
;...

[Zero Config]
ServerName = virtuoso (C1O-EIM-ODP01)
;ServerDSN			= ZDSN
;SSLServerName			=
;SSLServerDSN			=

[Mono]
;MONO_TRACE			= Off
;MONO_PATH			= <path_here>
;MONO_ROOT			= <path_here>
;MONO_CFG_DIR			= <path_here>
;virtclr.dll			=

[URIQA]
DynamicLocal = 0
DefaultHost  = localhost:8890

[SPARQL]
;ExternalQuerySource		= 1
;ExternalXsltSource 		= 1
;DefaultGraph      		= http://localhost:8890/dataspace
;ImmutableGraphs    		= http://localhost:8890/dataspace
ResultSetMaxRows           = 10000
MaxQueryCostEstimationTime = 400	; in seconds
MaxQueryExecutionTime      = 60	; in seconds
DefaultQuery               = SELECT ?date ?locazione ?unita_organizzativa ?etaMin ?etaMax ?genere ?numero WHERE{ ?entry npont:temporalID ?ti . FILTER( ?ti=201808 ) ?entry a npont:EntryAmministrati . ?entry npont:hasDate ?date . ?entry npont:howMany ?numero . ?entry npont:hasPlace ?p . ?p rdfs:label ?locazione . ?entry npont:hasGender ?gender . ?gender skos:notation ?genere . ?entry npont:inUO ?uo . ?uo rdfs:label ?unita_organizzativa . ?entry npont:hasAgeRange ?ar . OPTIONAL{ ?ar npont:minAge ?etaMin . } OPTIONAL{ ?ar npont:maxAge ?etaMax . } } LIMIT 200
DeferInferenceRulesInit    = 0	; controls inference rules loading
;PingService       		= http://rpc.pingthesemanticweb.com/

[Plugins]
LoadPath = /data/usr/local/lib/virtuoso/hosting
Load1    = plain, wikiv
Load2    = plain, mediawiki
Load3    = plain, creolewiki
;Load4			= plain, im
;Load5		= plain, wbxml2
;Load6			= plain, hslookup
;Load7			= attach, libphp5.so
;Load8			= Hosting, hosting_php.so
;Load9			= Hosting,hosting_perl.so
;Load10		= Hosting,hosting_python.so
;Load11		= Hosting,hosting_ruby.so
;Load12				= msdtc,msdtc_sample

Seeing also other comments im trying to use this new configuration

[Parameters]
NumberOfBuffers = 2720000
MaxDirtyBuffers = 2000000
MaxQueryMem = 2G

[SPARQL]
MaxQueryExecutionTime = 30
MaxQueryCostEstimationTime = 10
ResultSetMaxRows = 10000
Log_Enable = 2
Log_Dirs = logs

Do you think that it could helps too?

What is the current triple count and typical query work load against these Virtuoso servers ? As the NumberOfBuffers is set to 680K pages, with less than 300K in use, whereas the database 5549312 pages, 1604217 free indicate the database is about 4000000 pages in size. Thus is there a lot of unused data in the database not being touched by the typical query work load ?

Where did you get the log_enable & log_dirs param settings in the [SPARQL] section from as they are not valid ?

The MaxQueryCostEstimationTime param should be commented it as it is more for use when debugging queries.

From the Linux top output what is the wa wait time value on both machines hosting Virtuoso when the high CPU consumption is being observed.

What is the CPU type of the machines hosting Virtuoso ?

What is the Linux swappiness setting on the machines ?

Good morning,

Regarding swappines we set it to the lowest value but nothing changed.

Regarding the queries for the RDF Index counts I get the following, thus I dont have a bad index

OpenLink Virtuoso Interactive SQL (Virtuoso)
Version 07.20.3238 as of Jul 25 2024
Type HELP; for help and EXIT; to exit.
SQL> select count (s), count (p ), count (o ), count (g ) from rdf_quad   table option (index rdf_quad, check);
Connected to OpenLink Virtuoso
Driver: 07.20.3238 OpenLink Virtuoso ODBC Driver
count    count__1  count__2  count__3
INTEGER  INTEGER  INTEGER  INTEGER
_______________________________________________________________________________

463654651  463654651  463654651  463654651

1 Rows. -- 11369 msec.
SQL> select count (*) from rdf_quad a table option (index rdf_quad) where not exists (select 1 from rdf_quad b table option (loop, index rdf_quad_pogs) where a.g = b.g and a.p = b.p and a.o = b.o and a.s = b.s);
count
INTEGER
_______________________________________________________________________________

0

1 Rows. -- 683498 msec.
SQL> select count (*) from rdf_quad a table option (index rdf_quad_pogs) where not exists (select 1 from rdf_quad b table option (loop, index primary key) where a.g = b.g and a.p = b.p and a.o = b.o and a.s = b.s);
count
INTEGER
_______________________________________________________________________________

0

1 Rows. -- 70154 msec.
SQL> select count (*) from rdf_quad a table option (index rdf_quad_pogs) where not exists (select 1 from rdf_quad b table option (loop, index rdf_quad_op) where a.g = b.g and a.p = b.p and a.o = b.o and a.s = b.s);
count
INTEGER
_______________________________________________________________________________

0

1 Rows. -- 101278 msec.
SQL> select count (*) from rdf_quad a table option (index rdf_quad_pogs) where not exists (select 1 from rdf_quad b table option (loop, index rdf_quad_sp) where a.g = b.g and a.p = b.p and a.o = b.o and a.s = b.s);
count
INTEGER
_______________________________________________________________________________

0

1 Rows. -- 140206 msec.
SQL> select count (*) from rdf_quad a table option (index rdf_quad_pogs) where not exists (select 1 from rdf_quad b table option (loop, index rdf_quad_gs) where a.g = b.g and a.p = b.p and a.o = b.o and a.s = b.s);
count
INTEGER
_______________________________________________________________________________

0

1 Rows. -- 96058 msec.
SQL>

Also from the queries I ran in the following, I can see via status() that I have approximately 3 GB of data. I estimated via query Q6 that, given an estimate of 100 bytes per triple, I get 43 GB of data, which corresponds exactly to the size of the .db file. Again from status(), we can see that I have 1,641,567 free pages, or approximately 30% of the 3 GB of data. In the queries, I also requested the Q4 indexes, which as I understand them, are the default ones. In particular, from what I understand, the 30% of free pages indicate that I have fragmented space, which in the free edition of Virtuoso can benefit from manual checkpoints and (VACUUM DB.DBA.VACUUM()), which should recover the free space and compact the pages. Could you suggest me the best way to manage it?


OpenLink Virtuoso Interactive SQL (Virtuoso)
Version 07.20.3238 as of Jul 25 2024
Type HELP; for help and EXIT; to exit.
##################################################### Q1: See all tables in the database
SQL> SELECT TABLE_NAME, TABLE_TYPE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'DB';
Connected to OpenLink Virtuoso
Driver: 07.20.3238 OpenLink Virtuoso ODBC Driver
TABLE_NAME TABLE_TYPE
VARCHAR VARCHAR
_______________________________________________________________________________


0 Rows. -- 1 msec.
##################################################### Q2: How many triples do you have in total?
SQL> SELECT COUNT(*) AS total_triples FROM DB.DBA.RDF_QUAD;
total_triples
INTEGER
_______________________________________________________________________________

463654651

1 Rows. -- 340 msec.

##################################################### Q3: How many graphs do you have and how many triples per graph?
SQL> SPARQL SELECT ?g (COUNT(*) AS ?triples) WHERE { GRAPH ?g { ?s ?p ?o } } GROUP BY ?g ORDER BY DESC(?triples);
g triples
LONG VARCHAR LONG VARCHAR
_______________________________________________________________________________

https://graph.exampleT1.it/e-202506 7107654
https://graph.exampleT1.it/e-202509 6698549
https://graph.exampleT1.it/e-202503 6560843
https://graph.exampleT1.it/e-202507 6483709
https://graph.exampleT1.it/e-202505 6426869
https://graph.exampleT1.it/e-202508 6372993
https://graph.exampleT1.it/e-202412 6368475
https://graph.exampleT1.it/e-202502 6368095
https://graph.exampleT1.it/e-202501 6346197
https://graph.exampleT1.it/e-202504 6324759
https://graph.exampleT1.it/e-202411 6216966
https://graph.exampleT1.it/e-202312 6212774
https://graph.exampleT1.it/e-202406 6174834
https://graph.exampleT1.it/e-202410 6163965
https://graph.exampleT1.it/e-202306 6154955
https://graph.exampleT1.it/e-202405 6152944
https://graph.exampleT1.it/e-202404 6137679
https://graph.exampleT1.it/e-202403 6132222
https://graph.exampleT1.it/e-202402 6112295
https://graph.exampleT1.it/e-202311 6103000
https://graph.exampleT1.it/e-202401 6089652
https://graph.exampleT1.it/e-202310 6067666
https://graph.exampleT1.it/e-202309 5949045
https://graph.exampleT1.it/e-202409 5818111
https://graph.exampleT1.it/e-202305 5775240
https://graph.exampleT1.it/e-202304 5766235
https://graph.exampleT1.it/e-202303 5743714
https://graph.exampleT1.it/e-202301 5710913
https://graph.exampleT1.it/e-202302 5704659
https://graph.exampleT1.it/e-202212 5697276
https://graph.exampleT1.it/e-202307 5670513
https://graph.exampleT1.it/e-202211 5667101
https://graph.exampleT1.it/e-202206 5660176
https://graph.exampleT1.it/e-202308 5655323
https://graph.exampleT1.it/e-202205 5647806
https://graph.exampleT1.it/e-202408 5644963
https://graph.exampleT1.it/e-202407 5644859
https://graph.exampleT1.it/e-202204 5626947
https://graph.exampleT1.it/e-202201 5598887
https://graph.exampleT1.it/e-202106 5595338
https://graph.exampleT1.it/e-202105 5590426
https://graph.exampleT1.it/e-202104 5583091
https://graph.exampleT1.it/e-202202 5578499
https://graph.exampleT1.it/e-202210 5574746
https://graph.exampleT1.it/e-202203 5558688
https://graph.exampleT1.it/e-202111 5541186
https://graph.exampleT1.it/e-202112 5537171
https://graph.exampleT1.it/e-202101 5512725
https://graph.exampleT1.it/e-202110 5495475
https://graph.exampleT1.it/e-202209 5475790
https://graph.exampleT1.it/e-202103 5472811
https://graph.exampleT1.it/e-202102 5419126
https://graph.exampleT1.it/e-202012 5286487
https://graph.exampleT1.it/e-202006 5237571
https://graph.exampleT1.it/e-202011 5233766
https://graph.exampleT1.it/e-202005 5231517
https://graph.exampleT1.it/e-202004 5226612
https://graph.exampleT1.it/e-202207 5218551
https://graph.exampleT1.it/e-202003 5217121
https://graph.exampleT1.it/e-202109 5206782
https://graph.exampleT1.it/e-202002 5203933
https://graph.exampleT1.it/e-202001 5189352
https://graph.exampleT1.it/e-202208 5174685
https://graph.exampleT1.it/e-202010 5152021
https://graph.exampleT1.it/e-202107 5134255
https://graph.exampleT1.it/e-202108 5132712
https://graph.exampleT1.it/e-201912 5010493
https://graph.exampleT1.it/e-201906 4993835
https://graph.exampleT1.it/e-201905 4978498
https://graph.exampleT1.it/e-201904 4967751
https://graph.exampleT1.it/e-201911 4964645
https://graph.exampleT1.it/e-201903 4952973
https://graph.exampleT1.it/e-201902 4937274
https://graph.exampleT1.it/e-201910 4920238
https://graph.exampleT1.it/e-202007 4769899
https://graph.exampleT1.it/e-202008 4768844
https://graph.exampleT1.it/e-202009 4753693
https://graph.exampleT1.it/e-201907 4586914
https://graph.exampleT1.it/e-201908 4572766
https://graph.exampleT1.it/e-201909 4547510
https://graph.exampleT1.it/e-201901 3808506
https://graph.exampleT1.it/t 778250
https://graph.exampleT2.it/tP 166269
https://graph.exampleT2.it/eP-201706 135291
https://graph.exampleT2.it/eP-201806 129924
https://graph.exampleT2.it/eP-201906 124737
https://graph.exampleT2.it/eP-201702 121287
https://graph.exampleT2.it/eP-201704 120180
https://graph.exampleT2.it/eP-201701 119790
https://graph.exampleT2.it/eP-201708 119274
https://graph.exampleT2.it/eP-202006 118773
https://graph.exampleT2.it/eP-201703 118521
https://graph.exampleT2.it/eP-201710 118182
https://graph.exampleT2.it/eP-201705 117972
https://graph.exampleT2.it/eP-201712 117807
https://graph.exampleT2.it/eP-201707 117045
https://graph.exampleT2.it/eP-201709 116580
https://graph.exampleT2.it/eP-201802 116457
https://graph.exampleT2.it/eP-201711 115896
https://graph.exampleT2.it/eP-201804 115302
https://graph.exampleT2.it/eP-201801 114858
https://graph.exampleT2.it/eP-201808 114849
https://graph.exampleT2.it/eP-201810 113769
https://graph.exampleT2.it/eP-201803 113763
https://graph.exampleT2.it/eP-202106 113400
https://graph.exampleT2.it/eP-201812 113184
https://graph.exampleT2.it/eP-201805 112938
https://graph.exampleT2.it/eP-201807 112605
https://graph.exampleT2.it/eP-201902 112119
https://graph.exampleT2.it/eP-201809 112035
https://graph.exampleT2.it/eP-201811 111510
https://graph.exampleT2.it/eP-201904 111039
https://graph.exampleT2.it/eP-201901 110352
https://graph.exampleT2.it/eP-201908 109722
https://graph.exampleT2.it/eP-201903 109470
https://graph.exampleT2.it/eP-201910 108810
https://graph.exampleT2.it/eP-201905 108633
https://graph.exampleT2.it/eP-201912 108048
https://graph.exampleT2.it/eP-201907 107883
https://graph.exampleT2.it/eP-202206 107187
https://graph.exampleT2.it/eP-202002 107112
https://graph.exampleT2.it/eP-201909 107046
https://graph.exampleT2.it/eP-201911 106329
https://graph.exampleT2.it/eP-202004 106227
https://graph.exampleT2.it/eP-202001 105417
https://graph.exampleT2.it/eP-202008 104721
https://graph.exampleT2.it/eP-202003 104628
https://graph.exampleT2.it/eP-202010 104154
https://graph.exampleT2.it/eP-202012 103872
https://graph.exampleT2.it/eP-202005 103239
https://graph.exampleT2.it/eP-202007 102777
https://graph.exampleT2.it/eP-202009 102180
https://graph.exampleT2.it/eP-202102 102132
https://graph.exampleT2.it/eP-202011 102105
https://graph.exampleT2.it/eP-202104 101328
https://graph.exampleT2.it/eP-202306 101220
https://graph.exampleT2.it/eP-202101 100908
https://graph.exampleT2.it/eP-202108 100257
https://graph.exampleT2.it/eP-202103 99519
https://graph.exampleT2.it/eP-202110 99243
https://graph.exampleT2.it/eP-202105 98724
https://graph.exampleT2.it/eP-202112 98616
https://graph.exampleT2.it/eP-202107 98256
https://graph.exampleT2.it/eP-202109 97614
https://graph.exampleT2.it/eP-202202 97416
https://graph.exampleT2.it/eP-202111 96792
https://graph.exampleT2.it/eP-202406 96660
https://graph.exampleT2.it/eP-202201 96192
https://graph.exampleT2.it/eP-202204 96084
https://graph.exampleT2.it/eP-202203 94827
https://graph.exampleT2.it/eP-202208 94569
https://graph.exampleT2.it/eP-202205 93588
https://graph.exampleT2.it/eP-202210 93444
https://graph.exampleT2.it/eP-202207 92925
https://graph.exampleT2.it/eP-202212 92907
https://graph.exampleT2.it/eP-202506 92568
https://graph.exampleT2.it/eP-202209 91905
https://graph.exampleT2.it/eP-202302 91803
https://graph.exampleT2.it/eP-202211 91290
https://graph.exampleT2.it/eP-202304 90837
https://graph.exampleT2.it/eP-202301 90429
https://graph.exampleT2.it/eP-202303 89535
https://graph.exampleT2.it/eP-202308 89415
https://graph.exampleT2.it/eP-202310 88749
https://graph.exampleT2.it/eP-202305 88503
https://graph.exampleT2.it/eP-202312 88437
https://graph.exampleT2.it/eP-202307 87681
https://graph.exampleT2.it/eP-202402 87555
https://graph.exampleT2.it/eP-202309 87279
https://graph.exampleT2.it/eP-202404 86637
https://graph.exampleT2.it/eP-202311 86610
https://graph.exampleT2.it/eP-202401 86136
https://graph.exampleT2.it/eP-202408 85779
https://graph.exampleT2.it/eP-202410 85053
https://graph.exampleT2.it/eP-202403 85041
https://graph.exampleT2.it/eP-202405 84591
https://graph.exampleT2.it/eP-202412 84588
https://graph.exampleT2.it/eP-202407 83976
https://graph.exampleT2.it/eP-202502 83823
https://graph.exampleT2.it/eP-202409 83640
https://graph.exampleT2.it/eP-202504 83223
https://graph.exampleT2.it/eP-202411 83019
https://graph.exampleT2.it/eP-202501 82359
https://graph.exampleT2.it/eP-202508 82206
https://graph.exampleT2.it/eP-202503 81654
https://graph.exampleT2.it/eP-202505 80901
https://graph.exampleT2.it/eP-202507 80559
https://graph.exampleT2.it/eP-202509 79905
https://graph.exampleT1.it/entries 7955
http://localhost:8890/DAV/ 3065
http://www.openlinksw.com/schemas/virtrdf# 2484
https://graph.exampleT1.it/m 1362
https://graph.exampleT2.it/eP 1322
http://localhost:8890/DAV 1281
https://graph.exampleT1.it/ontology 998
https://graph.exampleT2.it/ontology 311
http://www.w3.org/2002/07/owl# 167
https://graph.exampleT2.it/mP 123
http://localhost:8890/sparql 14
http://www.w3.org/ns/ldp# 3
urn:activitystreams-owl:map 2

201 Rows. -- 3629 msec.
##################################################### Q4: View RDF indexes
SQL> SELECT KEY_NAME, KEY_N_SIGNIFICANT FROM SYS_KEYS WHERE KEY_TABLE = 'DB.DBA.RDF_QUAD';
KEY_NAME KEY_N_SIGNIFICANT
VARCHAR NOT NULL SMALLINT
_______________________________________________________________________________

DB.DBA.RDF_QUAD 4
RDF_QUAD_GS 2
RDF_QUAD_OP 2
RDF_QUAD_POGS 4
RDF_QUAD_SP 2

5 Rows. -- 2 msec.
##################################################### Q5: Space occupied by type
SQL> status();
REPORT
VARCHAR
_______________________________________________________________________________

OpenLink Virtuoso Server
Version 07.20.3238-pthreads for Linux as of Jul 25 2024 (d89671fa1)
Started on: 2025-09-30 18:34 GMT+2
CPU: 1303.27% RSS: 11098MB

Database Status:
File size 2975858688, 5606144 pages, 1641567 free.
680000 buffers, 654057 used, 7 dirty 20 wired down, repl age 353848884 0 w. io 13 w/crsr.
Disk Usage: 1867670 reads avg 0 msec, 0% r 0% w last 0 s, 1208472 writes flush 314.9 MB/s,
11937 read ahead, batch = 131. Autocompact 109822 in 79778 out, 27% saved col ac: 208591 in 7% saved.
Gate: 194961 2nd in reads, 0 gate write waits, 0 in while read 0 busy scrap.
Log = /data/usr/local/var/lib/virtuoso/db/virtuoso.trx, 10257 bytes
626857 pages have been changed since last backup (in checkpoint state)
Current backup prefix: backup_#
Current backup timestamp: 0x6E24-0x72-0xB2
Last backup date: Thu Jul 25 11:31:03 2024

Clients: 334 connects, max 12 concurrent
RPC: 25885359 calls, 7656 pending, 7658 max until now, 0 queued, 290 burst reads (0%), 0 second 75M large, 4079M max
Checkpoint Remap 0 pages, 0 mapped back. 54 s atomic time.
DB master 5606144 total 1641567 free 0 remap 0 mapped back
temp 250880 total 250872 free

Lock Status: 0 deadlocks of which 0 2r1w, 125536 waits,
Currently 14 threads running 0 threads waiting 0 threads in vdb.
Pending:

Client 1111:334: Account: dba, 1039 bytes in, 16938 bytes out, 1 stmts.
PID: 3369, OS: unix, Application: unknown, IP#: 127.0.0.1
Transaction status: PENDING, 1 threads.
Locks:


Running Statements:
Time (msec) Text
121 status()


Hash indexes


40 Rows. -- 122 msec.
##################################################### Q6: Space occupied by type
SQL> SELECT ROUND(COUNT(*) * 100.0 / 1024 / 1024 / 1024, 2) AS gb_estimated FROM DB.DBA.RDF_QUAD;
gb_estimated
DOUBLE PRECISION
_______________________________________________________________________________

43

1 Rows. -- 424 msec.
SQL>

Finally I found out using query logging that the query that creates the problems is this

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX exont: <http://example/ontology/>

SELECT ?ds ?lbl ?desc
WHERE {
  {
    SELECT DISTINCT ?ds
    WHERE {
      ?x a ?ds ;
         exont:hasTime ?t .
    }
  }
  ?ds rdfs:label ?lbl ;
      rdfs:comment ?desc .
  FILTER(lang(?lbl) = lang(?desc))
}

Could you suggest me a way to manage index such that this query can be faster? As I said, I undestood that I have only default indexes. This query requires 4 sec to be managed.

Thank you in advance

How long does the problem query you found take to run if run using the Virtuoso isql command line tool ?

Can you provide the explain and profile plans for the query as detailed in this post ?