1

SAPRQL INSERT WHERE在 GraphDB 上运行“大”,它似乎并没有使用所有可用的物理 RAM。

我正在使用 64GB、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

这是一个非推理回购,如果这有什么不同的话

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

这是内存利用率页面的截图

4

1 回答 1

2

默认情况下,GraphDB 将为其全局页面缓存分配 50% 的可用堆,该结构负责缓存所有磁盘页面并最小化 I/O 时间。该值在 conf/graphdb.properties 中由以 graphdb.page.cache.size 开头的行控制。在您的方案中,全局缓存默认设置为 25GB。

根据经验,如果所有索引都打开,您可以计算出一个包含 10 亿条 RDF 语句的存储库将占用大约 100GB 的磁盘空间。从堆内存使用图来看,您的数据集似乎不足以填满缓存大小。

对于使用快速 SSD 磁盘的设置,分配大于总存储库大小 15-30% 的更多缓存大小几乎没有什么区别。由于更长的 GC 周期,设置更大的堆大小甚至可能会损害 repo 的性能。我强烈建议您将最大堆大小限制为小于 32GB 以受益于-XX:+UseCompressedOops,这应该几乎等于没有指针压缩的 50GB 堆大小。此行为与管理大堆大小的其他 Java 应用程序一致。

于 2017-11-06T13:37:08.293 回答