我的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内部统计有很大不同 - 差异来自何处？为什么＆＃34; -g 1＆＃34;选项不起作用？当我运行一个简单的例子时，它工作正常。但在这种情况下，它似乎泄漏了大量内存。
我尝试使用2.6版本，它应该具有自动垃圾收集功能。令人惊讶的是，在单线程（每个）和多线程模式（桃子）中运行版本2.6时，.Q.w的使用和堆数之间仍然存在巨大差异。有什么想法吗？
答案 0 :(得分：2)
我不确定具体的答案，但这是我根据维基上提到的以下信息（以及一些实际实验）的推论： http://code.kx.com/q/ref/control/#peach 它说：
内存使用
每个从属线程都有自己的堆，最小为64MB。
由于主线程中的kdb 2.7 2011.09.21，.Q.gc []也在从属线程中执行gc。
每个线程内的自动垃圾收集（由wsful触发，或命中行上的-w指定的人为堆限制）仅针对该特定线程执行，而不是跨所有线程执行。
符号从所有线程共有的单个内存区域内部化。
我的观察：
.Q.w[]仅显示主线程的统计信息，而不显示所有线程的总和（总进程内存）。这可以通过用2个线程开始'q'来测试。在这种情况下，总内存应至少为128 MB，而点{1}，.Q.w[]仍显示64 MB。
这就是为什么在你的情况下，在开始时内存统计数据接近unix统计数据，因为所有数据都在主线程中而在其他线程上没有。执行某些操作后，某些线程可能占用了一些内存（使用/垃圾），但.Q.w[]未显示。
如wiki所述，在主线程上调用垃圾收集器会在所有线程上调用GC。这样就可以从线程中收集垃圾内存，并减少总内存使用量，这可以通过减少unix内存统计数据来反映。