gpt4 book ai didi

kdb - 为什么 kdb 进程在系统上显示高内存使用率?

转载 作者:行者123 更新时间:2023-12-02 01:30:49 25 4
gpt4 key购买 nike

我的 kdb 进程遇到了严重的内存问题。这里是简要的架构。

该进程以从属模式(4 个从属)运行。它最初将大量数据从数据库加载到内存中(从 -22 计算出的所有加载到内存中的变量的总大小约为 11G)。最初这匹配 .Q.w[] 并且接近 unix 进程内存使用。这个数据集在增量操作中增加的很少。但是,经过长时间的操作,虽然 kdb 内部内存统计信息 (.Qw[]) 显示预期的内存使用量(已使用和堆)~ 13 G,但该进程在系统上消耗了接近 25G(unix/proc,top)最终耗尽物理内存。

现在,当我手动运行垃圾回收 (.Q.gc[]) 时,它会释放内存并使 unix 进程使用率接近 .Q.w[] 显示的堆数。

我正在运行带有 -g 1 选项的 Q 2.7 版本以在立即模式下运行垃圾收集。

为什么 unix 进程使用情况与 kdb 内部统计数据有如此大的不同——差异来自哪里?为什么“-g 1”选项不起作用?当我运行一个简单的例子时,它工作正常。但在这种情况下,它似乎泄漏了大量内存。

我尝试使用应该具有自动垃圾收集功能的 2.6 版本。令人惊讶的是,在单线程(each)和多线程模式(peach)下使用 2.6 版运行时,.Q.w 中的已用数和堆数之间仍然存在巨大差异。有任何想法吗?

最佳答案

我不确定具体的答案,但这是我根据维基上提到的以下信息(和一些实际实验)得出的结论:
http://code.kx.com/q/ref/control/#peach
它说:
内存使用

Each slave thread has its own heap, a minimum of 64MB.

Since kdb 2.7 2011.09.21, .Q.gc[] in the main thread executes gc in the slave threads too.

Automatic garbage collection within each thread (triggered by a wsful, or hitting the artificial heap limit as specified with -w on the command line) is only executed for that particular thread, not across all threads.

Symbols are internalized from a single memory area common to all threads.


我的观察:
  • 线程特定内存:
  • .Q.w[]只显示主线程的统计信息,而不是所有线程的总和(总进程内存)。这可以通过用 2 个线程启动 'q' 来测试。在这种情况下,根据第 1 点,总内存至少应为 128MB,但 .Q.w[]它仍然显示 64 MB。
    这就是为什么在您的情况下,在开始时内存统计数据接近 unix 统计数据,因为所有数据都在主线程中,而在其他线程中没有任何数据。执行一些操作后,一些线程可能占用了一些内存(已用/垃圾), .Q.w[] 未显示这些内存。 .
  • 垃圾回收电话

  • 正如维基上提到的,在主线程上调用垃圾收集器会在所有线程上调用 GC。因此,这可能已经从线程中收集了垃圾内存并减少了总内存使用量,这反射(reflect)在 Unix 内存统计数据的减少上。

    关于kdb - 为什么 kdb 进程在系统上显示高内存使用率?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/34280985/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com