GraphDB에서 사용 가능한 메모리를 모두 사용하지 않습니다.

Question

GraphDB에서 "큰"SAPRQL INSERT WHERE을 실행 중이며 사용할 수있는 실제 RAM을 모두 사용하지 않는 것 같습니다. 내가 64 기가 바이트, 4 코어에 CentOS 6.9 서버

-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 

을 사용하고

나는이 같은 GraphDB 8.3.0 시작 :

graphdb -Xms50g -Xmx50g -d 

그것은 그 경우, 비 추론 REPO의 어떤 차이가 여기에

가 sysinfo가 페이지의 말씀입니다 수

응용 프로그램 정보 :

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 인수

-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 - 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 

그리고 메모리 utilzation 페이지

의 스크린 샷입니다

Answer 1

기본적으로 GraphDB는 모든 디스크 페이지 캐싱과 I/O 시간 최소화를 담당하는 글로벌 페이지 캐시에 사용 가능한 힙의 50 %를 할당합니다. 값은 conf/graphdb.properties에서 graphdb.page.cache.size로 시작하는 라인으로 제어됩니다. 시나리오에서 전역 캐시는 기본적으로 25GB로 설정됩니다.

일반적으로 10 억 개의 RDF 문이있는 저장소는 모든 인덱스가 켜져 있으면 약 100GB의 디스크 공간을 차지한다고 계산할 수 있습니다. 힙 메모리 사용 다이어그램에서 데이터 세트가 캐시 크기를 채우기에 충분하지 않은 것처럼 보입니다.

빠른 SSD 디스크를 사용하는 설정의 경우 전체 저장소 크기의 15-30 %보다 큰 캐시 크기를 할당하는 데 약간의 차이가 있습니다. 힙 크기를 더 크게 설정하면 GC주기가 길어져 repo의 성능이 저하 될 수 있습니다. -XX:+UseCompressedOops의 이점을 얻기 위해 최대 힙 크기를 32GB 미만으로 제한하는 것이 좋습니다. 포인터 압축을 사용하지 않는 경우 50GB 힙 크기와 거의 동일해야합니다. 이 동작은 big heaps sizes을 관리하는 다른 Java 응용 프로그램과 일치합니다.