监控系统
GDS 支持多个用户同时在同一系统上工作。通常,GDS 过程在资源方面很密集,因为它们可能使用大量内存和/或多个 CPU 内核来进行计算。为了了解用户运行 GDS 过程是否合理,了解承载 Neo4j 和 GDS 的系统的当前容量以及系统上的当前 GDS 工作负载非常有用。默认情况下,图和模型不会在非管理员用户之间共享,但是同一系统上的 GDS 用户将共享其容量。
系统监控过程
为了能够概述系统的当前容量及其分析工作负载,可以使用过程 gds.systemMonitor
。它将提供有关数据库管理系统 JVM 实例的内存和 CPU 内核容量的信息,以及对系统上当前正在运行的 GDS 过程所消耗的资源的概述。
语法
CALL gds.systemMonitor()
YIELD
freeHeap,
totalHeap,
maxHeap,
jvmAvailableCpuCores,
availableCpuCoresNotRequested,
jvmHeapStatus,
ongoingGdsProcedures
名称 | 类型 | 描述 |
---|---|---|
freeHeap |
整数 |
承载 Neo4j 实例的 Java 虚拟机中当前空闲内存的字节数。 |
totalHeap |
整数 |
承载 Neo4j 实例的 Java 虚拟机中的总内存字节数。此值可能会随时间变化,具体取决于主机环境。 |
maxHeap |
整数 |
承载 Neo4j 实例的 Java 虚拟机将尝试使用的最大内存字节数。 |
jvmAvailableCpuCores |
整数 |
Java 虚拟机当前可用的逻辑 CPU 内核数。此值可能会在数据库管理系统的生命周期中发生变化。 |
availableCpuCoresNotRequested |
整数 |
Java 虚拟机当前可用的逻辑 CPU 内核数,这些内核未被当前正在运行的 GDS 过程请求使用。请注意,如果 JVM 可用的内核少于当前正在运行的 GDS 过程请求的内核,则此数字可能为负。 |
jvmHeapStatus |
映射 |
以上提到的堆指标以人类可读的形式表示。 |
ongoingGdsProcedures |
映射列表 |
包含所有 GDS 过程(所有用户的)的资源使用情况和进度信息的映射列表,这些过程当前正在 Neo4j 实例上运行。每个映射都包含过程的名称、其执行进度、估计的内存使用量以及它最多将尝试使用的 CPU 内核数。 |
示例
首先,让我们假设我们刚刚启动了 gds.node2vec.stream
过程,并带有一些任意参数。
我们可以查看 JVM 堆的状态。
CALL gds.systemMonitor()
YIELD
freeHeap,
totalHeap,
maxHeap
freeHeap | totalHeap | maxHeap |
---|---|---|
1234567 |
2345678 |
3456789 |
我们可以看到,在运行 Neo4j 数据库管理系统的 JVM 实例中,当前大约有 1.23 MB
的空闲堆内存。这可能会独立于任何过程完成其执行而增加,因为 totalHeap
当前小于 maxHeap
。我们还可以检查 CPU 内核使用情况以及系统上当前正在运行的 GDS 过程的状态。
CALL gds.systemMonitor()
YIELD
availableCpuCoresNotRequested,
jvmAvailableCpuCores,
ongoingGdsProcedures
jvmAvailableCpuCores | availableCpuCoresNotRequested | ongoingGdsProcedures |
---|---|---|
100 |
84 |
[{ username: "bob", jobId: "42", procedure: "Node2Vec", progress: "33.33%", estimatedMemoryRange: "[123 kB … 234 kB]", requestedNumberOfCpuCores: "16" }] |
这里我们可以注意到,目前只有一个 GDS 过程正在运行,即我们刚刚启动的 Node2Vec
过程。它已经完成了大约 33.33%
的执行。我们还看到它可能最多使用 234 kB
的内存。请注意,它目前可能没有使用那么多内存,因此它以后在执行过程中可能需要更多内存,从而可能降低我们当前的 freeHeap
。显然,它希望使用多达 16
个 CPU 内核,使我们系统中目前有 84
个内核未被任何 GDS 过程请求。