GraphDB wird nicht den gesamten verfügbaren Speicher verwenden

Question

Ich habe eine "große" SAPRQL INSERT WHERE auf GraphDB und es scheint nicht alle verfügbaren physikalischen RAM zu verwenden.

ich eine 64GB bin mit 4-Kern CentOS 6.9 Server

-bash-4.1$ free -m 
      total  used  free  shared buffers  cached 
Mem:   64428  21897  42530   0  107  2877 
-/+ buffers/cache:  18912  45515 
Swap:   8095   0  8095 

Ich begann GraphDB 8.3.0 wie folgt aus:

graphdb -Xms50g -Xmx50g -d 

Es ist eine nicht-Inferenz-Repo, wenn das macht einen Unterschied

was hier die sysinfo Seite sagt

Anwendung Info:

OS: Linux 2.6.32-696.6.3.el6.x86_64 
Java: Oracle Corporation 1.8.0_144 
Memory used: 5554 MB 
Max memory: 50977 MB 

JVM Argumente

-Xms1g 
-Djava.awt.headless=true 
-Dfile.encoding=UTF-8 
-Djava.net.preferIPv4Stack=true 
-XX:+UseParallelGC 
-XX:-OmitStackTraceInFastThrow 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/usr/local/graphdb/heapdump.hprof 
-XX:OnOutOfMemoryError=kill -9 %p 
-Dgraphdb.dist=/usr/local/graphdb 
-Xms50g 
-Xmx50g 

Top-Ausgang:

top - 13:32:23 up 22:37, 1 user, load average: 1.00, 0.96, 0.76 
Tasks: 153 total, 1 running, 152 sleeping, 0 stopped, 0 zombie 
Cpu(s): 25.1%us, 0.2%sy, 0.0%ni, 74.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st 
Mem: 65974292k total, 22390544k used, 43583748k free, 109900k buffers 
Swap: 8290300k total,  0k used, 8290300k free, 2915740k cached 

    PID USER  PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
4071 sprqlusr 20 0 56.2g 17g 22m S 101.0 28.4 16:53.29 /usr/local/java/bin/java -Xms1g -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djava.net.preferIPv4Stack=true -XX:+UseParallelGC -XX:-OmitStackTraceInFastThrow -XX:+HeapDumpO 

Und hier ist ein Screenshot von der Speicher utilzation Seite

Answer 1

Standardmäßig reserviert GraphDB 50% des verfügbaren Heapspeichers für seinen globalen Seitencache, die Struktur, die für das Zwischenspeichern aller Festplattenseiten und die Minimierung der E/A-Zeit verantwortlich ist. Der Wert wird in conf/graphdb.properties durch eine Zeile gesteuert, die mit graphdb.page.cache.size beginnt. In Ihrem Szenario ist der globale Cache standardmäßig auf 25 GB festgelegt.

Als Faustregel können Sie berechnen, dass ein Repository mit 1 Milliarde RDF-Anweisungen etwa 100 GB Speicherplatz benötigt, wenn alle Indizes eingeschaltet sind. Aus dem Heap-Speicherverwendungsdiagramm sieht es so aus, als ob Ihre Datenmenge gerade nicht groß genug ist, um die Cache-Größe zu füllen.

Für Setups mit schnellen SSD-Festplatten ist es sehr wenig sinnvoll, mehr Cache-Größe zuzuweisen, die größer als 15-30% der gesamten Repository-Größe ist. Das Festlegen einer größeren Heap-Größe kann aufgrund der längeren GC-Zyklen sogar die Leistung des Repos beeinträchtigen. Ich empfehle Ihnen, Ihre maximale Heap-Größe auf weniger als 32 GB zu beschränken, um von der -XX:+UseCompressedOops zu profitieren, die der 50-GB-Heap-Größe ohne die Pointer-Komprimierung fast gleichwertig sein sollte. Dieses Verhalten ist konsistent mit anderen Java-Anwendungen, die big heaps sizes verwalten.