监控系统

GDS 支持多个用户在同一系统上并发工作。通常，GDS 过程属于资源密集型，这意味着它们可能会占用大量内存和/或多个 CPU 核心来进行计算。为了了解用户此时运行 GDS 过程是否合适，了解托管 Neo4j 和 GDS 的系统的当前容量以及系统上当前的 GDS 工作负载非常有用。默认情况下，非管理员用户之间不共享图和模型，但同一系统上的 GDS 用户会共享其容量。

系统监控过程

为了能够概览系统的当前容量及其分析工作负载，可以使用 gds.systemMonitor 过程。它将为您提供 DBMS 的 JVM 实例在内存和 CPU 核心方面的容量信息，以及当前在系统上运行的 GDS 过程所消耗资源的概览。

语法

监控系统容量和分析工作负载

CALL gds.systemMonitor()
YIELD
  freeHeap,
  totalHeap,
  maxHeap,
  jvmAvailableCpuCores,
  availableCpuCoresNotRequested,
  jvmHeapStatus,
  ongoingGdsProcedures

表 1. 结果
名称	类型	描述
freeHeap	整数	托管 Neo4j 实例的 Java 虚拟机中当前空闲的内存量（以字节为单位）。
totalHeap	整数	托管 Neo4j 实例的 Java 虚拟机中的内存总量（以字节为单位）。此值可能会随时间变化，具体取决于主机环境。
maxHeap	整数	托管 Neo4j 实例的 Java 虚拟机将尝试使用的最大内存量（以字节为单位）。
jvmAvailableCpuCores	整数	当前可供 Java 虚拟机使用的逻辑 CPU 核心数。此值可能会在 DBMS 的生命周期内发生变化。
availableCpuCoresNotRequested	整数	当前可供 Java 虚拟机使用且未被当前运行的 GDS 过程请求占用的逻辑 CPU 核心数。请注意，如果 JVM 可用的核心数少于正在进行的 GDS 过程请求的核心数，则此数字可能为负数。
jvmHeapStatus	Map	以人类可读形式呈现的上述堆指标。
ongoingGdsProcedures	映射列表	包含当前在 Neo4j 实例上运行的所有 GDS 过程（所有用户）的资源使用情况和进度信息的映射列表。每个映射包含过程名称、进度、估计内存使用量以及它最多尝试使用的 CPU 核心数。

freeHeap 受正在进行的 GDS 过程、存储在图目录中的图以及底层 Neo4j DBMS 的影响。存储的图会占用大量的堆内存。要检查图目录中的图，可以使用图列表过程。

示例

首先，假设我们刚刚以一些任意参数启动了 gds.node2vec.stream 过程。

我们可以查看 JVM 堆的状态。

监控 JVM 堆状态

CALL gds.systemMonitor()
YIELD
  freeHeap,
  totalHeap,
  maxHeap

表 2. 结果
freeHeap	totalHeap	maxHeap
1234567	2345678	3456789

我们可以看到，运行我们 Neo4j DBMS 的 JVM 实例中目前大约有 1.23 MB 的空闲堆内存。由于 totalHeap 当前小于 maxHeap，此值可能会在任何过程结束执行之前独立增加。我们还可以检查 CPU 核心使用情况以及系统上当前运行的 GDS 过程的状态。

监控 CPU 核心使用情况和正在进行的 GDS 过程

CALL gds.systemMonitor()
YIELD
  availableCpuCoresNotRequested,
  jvmAvailableCpuCores,
  ongoingGdsProcedures

表 3. 结果
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 过程请求的核心。

内存报告过程

为了促进内存管理，Neo4j GDS 库除了上述监控功能外，还提供了两个内存报告过程。

详细内存列表

通过 gds.memory.list 过程，用户可以获得其投影图和正在运行的任务及其内存占用的汇总列表。

对于图，返回的是内存中图的大小；而对于算法，返回的是内存估计值，即该任务预计在其执行过程中所需的最大内存需求。

此过程可以帮助用户了解哪些操作可能占用大量内存并据此进行规划（例如，删除某个图或终止事务）。

用户只能访问自己的图或任务，但管理员可以获取所有用户的信息。

语法

列出用户的图和任务及其内存占用情况。

CALL gds.memory.list()
YIELD
  user: String,
  name: String,
  entity: String
  memoryInBytes: Integer

表 4. 结果
名称	类型	描述
user（用户）	字符串	用户名
名称 (name)	字符串	图或正在运行的任务的名称。
实体 (entity)	字符串	如果报告实体是任务，则这对应于其作业 ID。否则，它被设置为 "graph"。
memoryInBytes	整数	图占用的内存或任务的预估内存。

示例

列出 Bob 正在运行的任务和图。

CALL gds.memory.list()
YIELD
  user, name, entity, memoryInBytes

表 5. 结果
user（用户）	名称 (name)	实体 (entity)	memoryInBytes
"Bob"	"my-graph"	"graph"（图）	20
"Bob"	"Node2Vec"	111-222-333	234

正如我们所见，Bob 已经投影了一个名为 'my-graph' 的图，占用了 200 字节内存，并且目前正在运行内存占用为 234 字节的 Node2Vec。

内存摘要

gds.memory.summary 过程提供了给定用户的总图内存以及正在运行的任务的总内存需求的概览。

用户只能访问自己的图或任务，但管理员可以获取所有用户的信息。

语法

列出用户的图和任务及其内存占用情况。

CALL gds.memory.summary()
YIELD
  user: String,
  totalGraphsMemory : Intger,
  totalTasksMemory : Integer

表 6. 结果
名称	类型	描述
user（用户）	字符串	用户名。
totalGraphsMemory	整数	该用户图的总需求。
totalTasksMemory	整数	该用户任务的总需求。

示例

列出 Bob 正在运行的任务和图。

CALL gds.memory.summary()
YIELD
  user, totalGraphsMemory, totalTasksMemory

表 7. 结果
user（用户）	totalGraphsMemory	totalTasksMemory
"Bob"	20	234