监控系统

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 虚拟机当前可用的逻辑 CPU 核心数，未被当前运行的 GDS 过程请求使用。请注意，如果 JVM 可用的核心数少于正在进行的 GDS 过程请求的核心数，此数字可能为负。
jvmHeapStatus	映射	上述堆度量以人类可读形式呈现。
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. 结果
名称	类型	描述
用户	字符串	用户名
名称	字符串	图或正在运行的任务的名称。
实体	字符串	如果报告实体是任务，则对应其作业 ID。否则，设置为“图”。
memoryInBytes	整数	图占用的内存或任务的估算内存。

示例

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

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

表 5. 结果
用户	名称	实体	memoryInBytes
"Bob"	"my-graph"	"graph"	20
"Bob"	"Node2Vec"	111-222-333	234

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

内存摘要

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

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

语法

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

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

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

示例

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

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

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