内存管理

在 controller 上提供函数 getClusterPerf() 函数，显示集群中各个节点的内存占用情况。包括： memoryAlloc：节点上分配的总内存，近似于向操作系统申请的内存总和。
memoryUsed：节点已经使用的内存。该内存包括变量、分布式表缓存以及各种缓存队列等。
maxMemSize：节点可使用的最大内存限制。

mem() 函数可以显示整个节点的内存分配和占用情况。allocatedBytes 为已分配内存；freeBytes 是可用内存。两者之差为已占用内存。通过 mem().allocatedBytes - mem().freeBytes 得到节点所使用的总的内存大小。（注：如使用 1.20.0 及更早版本，通过 sum(mem().allocatedBytes - mem().freeBytes) 进行计算。）

通过函数 objs 来查看会话内所有变量的内存占用。该函数返回一个表，其中列 bytes 表示变量占用的内存块大小。objs(true) 除返回当前会话中变量的内存占用外，还返回共享变量的内存占用（包括其他会话共享的变量）。

通过函数 memSize 来查看某个对象占用内存的具体大小，单位为字节。比如

v=1..1000000
memSize(v)

输出：4000000。

可通过函数 getSessionMemoryStat() 查看节点上每个 session 占用的内存量，输出结果只包含 session 内定义的变量。由于共享表和分布式表不属于某个用户或会话，因此返回结果中不包含它们占用的内存信息。由于输出结果亦包含用户名，也可查看每个用户的内存使用情况。

以上方法无法获取后台运行任务所占用的内存。可以通过函数 getRecentJobs 来查看正在运行的后台任务。目前，DolphinDB 无法通过函数查看后台任务的内存占用情况，需用户根据业务逻辑进行估算。若内存比较紧张，可以取消一些暂无必要执行的后台任务，以释放内存空间。

若节点内存接近 warningMemSize，通过函数 clearAllCache() 来手动释放节点的缓存数据。如果内存占用仍然未显著降低，请依次排查下述问题：

• 通过函数 getSessionMemoryStat() 结合 objs() 和 objs(true) 排查是否某个用户忘记 undef 了变量 ;

• 通过函数 getRecentJobs() 和 getConsoleJobs() 查看是否还有超过预期运行时长的后台或交互任务。运行中的任务的内存占用不反映在 getSessionMemoryStat() ;

• getStreamingStat() 查看流数据内存占用，详见 流数据消息缓存队列。

该异常往往是由于 query 所需的内存大于系统可提供的内存导致的。请先执行下列脚本查看所有数据节点内存使用情况，其中 maxMemSize 为配置的节点最大可用内存，memoryUsed 为节点已使用内存，memoryAlloc 为节点已分配内存。

select site, maxMemSize, memoryUsed, memoryAlloc from rpc(getControllerAlias(),getClusterPerf)

OOM 一般可能由以下原因导致:

• 查询没有加分区过滤条件或者条件太宽，导致单个 query 涉及的数据量太大。

  查询涉及多少分区可用 sqlDS 函数来判断，示例脚本如下：

  ds=sqlDS(<select * from loadTable("dfs://demo","sensor")>)
  ds.size()

  为避免这个问题，参见本文档的DolphinDB 按照分区进行数据检索 ，更详细的说明请参考教程 SQL 案例分区剪枝

• 写入缓存占用了大量内存。

  getCacheEngineMemSize() //查看 OLAP 引擎的 Cache Engine 占用内存
  getTSDBCacheEngineSize() //查看 TSDB 引擎的 Cache Engine 占用内存

  为避免这个问题，请参考本文档 为分布式数据库提供写入缓存

• 分区不均匀。可能某个分区过大，该分区的数据超过节点配置的最大内存。

  查询每个分区的大小可用 getTabletsMeta 函数，例如：

  getTabletsMeta("/demo/%", `sensor, true);

  为避免这个问题，参见分区设计注意事项。

• 某个 session 持有大的变量，导致节点可用的内存很小。

  可以通过函数 getSessionMemoryStat() 查看各个 session 占用的内存大小。

• 某个 session 持有大的变量，导致节点可用的内存很小。 通过函数 getSessionMemoryStat() 查看各个 session 占用的内存大小及各 session 对应的用户。

  通过以下脚本查看每个数据节点上定义的变量和占用的内存：

  pnodeRun(objs) //查询每个节点定义变量占用内存（非共享变量）
  pnodeRun(objs{true}) //查询每个节点定义变量占用内存（包含共享变量）

  为避免这个问题，请参考本文档高效使用内存下的“及时释放数据量较大的变量”

• 流数据计算引擎占用了大量内存。

  用 getStreamingStat() 来查看发布、订阅各个队列的深度。用 getStreamEngineStat() 查看流计算引擎占用内存。

  为避免这个问题，请参考本文档 流数据消息缓存队列。

这种情况往往是由于给节点分配的内存超过系统物理内存的限制，操作系统把 DolphinDB 强制关闭。Linux 内核有个机制叫 OOM killer(Out of Memory killer)，该机制会监控那些占用内存过大，尤其是瞬间占用很大内存的进程，为防止内存耗尽而自动把该进程杀掉。排查 OOM killer 可用 dmesg 命令，示例如下：

dmesg -T|grep dolphindb

若打印结果中出现了“Out of memory: Kill process”，说明操作系统杀死了 DolphinDB 进程（详情请见 Linux Kernel 相关文档）。解决这种问题的办法是：通过参数 maxMemSize（单节点模式修改 dolphindb.cfg，集群模式修改 cluster.cfg）设定节点的最大内存使用量。

这是由于未使用的内存没有及时释放给操作系统。通过 memoryReleaseRate 控制将未使用的内存释放给操作系统的速率，memoryReleaseRate=10 表示以最快的速度释放内存，默认值是 5。该参数等价于设置了 TCMalloc 的 tcmalloc_release_rate。

注：执行 mem() 以显示本地节点内存使用情况。如设置其参数 freeUnusedBlocks=true，系统将会释放未使用的内存块。

可检查 log 中是否打印 Cache Engine 相关的信息。若存在这样的信息，说明使用 loadText 加载到内存的事务超过了 chunkCacheEngineMemSize 或 TSDBCacheEngineSize 的大小，导致事务卡死。

解决方案如下：

调大配置中的 chunkCacheEngineMemSize 或 TSDBCacheEngineSize 值。

2.00.4 及以上版本，请使用 loadTextEx 函数加载数据。这是因为 loadTextEx 函数可以通过参数 atomic，设置将大文件加载过程拆分为多个事务进行。

DolphinDB 是 C++ 程序，本身需要一些基础的数据结构和内存开销，memoryAlloc 显示内存不包括这些内存。在执行 clearAllCache 后，如果 memoryAlloc 的值占操作系统实际显示值的 80% 以上，属于正常现象。

DolphinDB 采用列式存储，当用户对分布式表的数据进行查询时，加载数据的原则是，只把用户所要求的分区和列加载到内存中。

示例 4. 计算分区 2022.01.01 最大的 tag1 的值。我们只查询 1 个分区的一列数据，仅把该列数据全部加载到内存，其他的列不加载。

该分区储存在 node1 上（可以在 controller 上通过函数 getClusterChunksStatus() 查看分区分布情况，而且由上面可知，每列约 80MB）。在 node1 上 执行如下代码，并查看内存占用。

select max(tag1) from loadTable(dbName,tableName) where day = 2022.01.01
mem().allocatedBytes - mem().freeBytes)

输出结果为 84,267,136。

示例 5. 在 node1 上查询 2022.01.01 的前 100 条数据，并观察内存占用。

select top 100 * from loadTable(dbName,tableName) where day = 2022.01.01
mem().allocatedBytes - mem().freeBytes

输出结果为 839,255,392。虽然我们只取 100 条数据，但是 DolphinDB 加载数据的最小单位是分区列，所以需要加载每个列的全部数据，也就是整个分区的全部数据，约 800MB。

注意： 合理分区以避免 "out of memory"：DolphinDB 以分区为单位管理内存，因此内存的使用量跟分区关系密切。假如分区不均匀，导致某个分区数据量超大，甚至机器的全部内存都不足以容纳整个分区，那么当涉及到该分区的查询计算时，系统会抛出 "out of memory" 的异常。一般原则，数据表的每个分区的数据量在 100MB-1GB 之间为宜。如果表有 10 列，每个字段 8 字节，则每个分区约 100-200 万行。

在数据量大的情况下，节点间转移数据是非常耗时的操作。DolphinDB 的数据是分布式存储的，当执行任务时，把任务发送到数据所在的节点，然后把结果汇总到发送任务的节点。系统会尽最大努力避免将数据跨节点转移。

示例 6. 在 node1 上计算两个分区中 tag1 的最大值。其中分区 2022.01.02 的数据存储在 node1 上，分区 2022.01.03 的数据存储在 node2 上。

select max(tag1) from loadTable(dbName,tableName) where day in [2022.01.02,2022.01.03]
mem().allocatedBytes - mem().freeBytes

输出结果为 84,284,096。在 node2 上查看内存占用为 84,250,624 字节。每个节点存储的数据都为 80MB 左右，也就是 node1 上存储了分区 2022.01.02 的数据，node2 上仅存储了 2022.01.03 的数据。

示例 7. 在 node1 上查询分区 2022.01.02 和 2022.01.03 的所有数据，我们预期 node1 加载 2022.01.02 数据，node2 加载 2022.01.03 的数据，都是 800MB 左右，执行如下代码并观察内存。

select top 100 * from loadTable(dbName,tableName) where day in [2022.01.02,2022.01.03]
mem().allocatedBytes - mem().freeBytes

node1 上输出结果为 839,279,968 字节。node2 上输出结果为 839,246,496 字节。结果符合预期。

注意： 请谨慎使用没有过滤条件的 "select *"，因为这会将所有数据载入内存。特别在列数很多的时候，建议仅加载需要的列。

DolphinDB 支持海量数据的并发查询。为了高效利用内存，对相同分区的数据，内存中只保留同一份副本。

示例 8. 打开两个 GUI，分别连接 node1 和 node2，查询分区 2022.01.01 的数据，该分区的数据存储在 node1 上。

select * from loadTable(dbName,tableName) where date = 2022.01.01
mem().allocatedBytes - mem().freeBytes

node1 上内存显示 839,101,024，而 node2 上无内存占用。系统将分区数据载入 node1 内存，然后将数据传输到 node2 内存，最后下载到客户端。之后，系统会将此次操作在 node2 所用内存释放。

通常情况下，最近访问的数据往往更容易再次被访问，因此 DolphinDB 在内存允许的情况下（内存占用不超过用户设置的 warningMemSize），尽量多缓存数据，来提升后续查询效率。

示例 9. 数据节点设置的 maxMemSize=10,warningMemSize=8。连续加载 9 个分区，每个分区约 800M，总内存占用约 7.2GB，观察内存的变化趋势。

dbPath =  right(dbName,strlen(dbName)-5)
p = select top 9 * from rpc(getControllerAlias(),getClusterChunksStatus) 
    where file like dbPath +"%" and replicas like "node1%" //这里节点1的别名为node1
    order by file
days = datetimeParse(t.file.substr(strlen(dbPath)+1,8),"yyyyMMdd")
for(d in days){
    select * from loadTable(dbName,tableName) where  date= d
    print mem().allocatedBytes - mem().freeBytes
}

内存随着加载分区数的增加变化规律如下图所示：

当遍历每个分区数据时，在内存使用量不超过 warningMemSize 的情况下，分区数据会全部缓存到内存中，以便用户下次访问时，直接从内存中读取数据，而不需要再次从磁盘加载。

当总的内存使用达到 warningMemSize 时，DolphinDB 会采用 LRU 的内存回收策略，回收一部分内存。

示例 10. 上面用例只加载了 9 天的数据，此时我们继续共遍历 15 天数据，查看缓存达到 warningMemSize 时，内存的占用情况。如下图所示：

如上图所示，当缓存的数据超过 warningMemSize 时，系统自动回收内存，总的内存使用量仍然小于用户设置的 warningMemSize。

示例 11. 当缓存数据接近用户设置的 warningMemSize 时，继续申请 Session 变量的内存空间，查看系统内存占用。

此时先查看系统的内存使用：

mem().allocatedBytes - mem().freeBytes

输出结果为 7,550,138,448。内存占用超过 7GB，而用户设置的最大内存使用量为 10GB，此时我们继续申请 4GB 空间。

v = 1..1000000000
mem().allocatedBytes - mem().freeBytes

输出结果为 8,196,073,856。约为 8GB，也就是如果用户定义变量时，可使用的内存不足，系统会触发缓存数据的内存回收，以保证有足够的内存提供给用户使用。