维维特不断耗尽记忆

Question

我试图运行一个weaviate实例，但是遇到了内存消耗问题。我已经在一个拥有16 1M内存的docker容器中运行，从文档中可以看出，它已经足够处理超过100万条记录了(我使用的是384个dim向量，就像在示例中一样)。

连接到weaviate的应用程序不断地插入和查询数据。内存使用量持续上升，直到内存耗尽，停靠器容器死亡。这是大约20k的记录。

这是垃圾收集永远不会发生的问题吗？

更新：

所讨论的weaviate版本为1.10.1，目前不使用任何模块。传入的记录已经有向量，所以没有使用向量器。应用程序根据一些元数据和nearVector过滤器搜索类似于传入记录的记录，然后插入传入记录。我将升级到1.12.1，看看这是否有帮助，但同时，这里有一些建议的内存测量。

7k记录：

docker统计内存使用情况: 2.56GB /16

gc 1859 @750.550s 0%: 0.33+33+0.058 ms clock, 26+1.2/599/1458+4.6 ms cpu, 2105->2107->1102 MB, 2159 MB goal, 80P
gc 1860 @754.322s 0%: 0.17+34+0.094 ms clock, 13+1.0/644/1460+7.5 ms cpu, 2150->2152->1126 MB, 2205 MB goal, 80P
gc 1861 @758.598s 0%: 0.39+35+0.085 ms clock, 31+1.4/649/1439+6.8 ms cpu, 2197->2199->1151 MB, 2253 MB goal, 80P

11k记录：

docker统计内存使用情况: 5.46GB /16

gc 1899 @991.964s 0%: 1.0+65+0.055 ms clock, 87+9.9/1238/3188+4.4 ms cpu, 4936->4939->2589 MB, 5062 MB goal, 80P
gc 1900 @999.496s 0%: 0.17+58+0.067 ms clock, 13+2.8/1117/3063+5.3 ms cpu, 5049->5052->2649 MB, 5178 MB goal, 80P
gc 1901 @1008.717s 0%: 0.38+65+0.072 ms clock, 30+2.7/1242/3360+5.7 ms cpu, 5167->5170->2710 MB, 5299 MB goal, 80P

17k记录：

docker统计内存使用情况: 11.25GB /16

gc 1932 @1392.757s 0%: 0.37+110+0.019 ms clock, 30+4.6/2130/6034+1.5 ms cpu, 10426->10432->5476 MB, 10694 MB goal, 80P
gc 1933 @1409.740s 0%: 0.14+108+0.052 ms clock, 11+0/2075/5666+4.2 ms cpu, 10679->10683->5609 MB, 10952 MB goal, 80P
gc 1934 @1427.611s 0%: 0.31+116+0.10 ms clock, 25+4.6/2249/6427+8.2 ms cpu, 10937->10942->5745 MB, 11218 MB goal, 80P

20k记录：

docker统计内存使用率: 15.22GB /16

gc 1946 @1658.985s 0%: 0.13+136+0.077 ms clock, 10+1.1/2673/7618+6.1 ms cpu, 14495->14504->7600 MB, 14866 MB goal, 80P
gc 1947 @1681.090s 0%: 0.28+148+0.045 ms clock, 23+0/2866/8142+3.6 ms cpu, 14821->14829->7785 MB, 15201 MB goal, 80P
GC forced
gc 16 @1700.012s 0%: 0.11+2.0+0.055 ms clock, 8.8+0/20/5.3+4.4 ms cpu, 3->3->3 MB, 7MB goal, 80P
gc 1948 @1703.901s 0%: 0.41+147+0.044 ms clock, 33+0/2870/8153+3.5 ms cpu, 15181->15186->7973 MB, 15570 MB goal, 80P
gc 1949 @1728.327s 0%: 0.29+156+0.048 ms clock, 23+18/3028/8519+3.9 ms cpu, 15548->15553->8168 MB, 15946 MB goal, 80P

pprof

     flat  flat%  sum%          cum   cum%
7438.24MB 96.88% 96.88%   7438.74MB 96.88%  github.com/semi-technologies/weaviate/adapters/repos/db/inverted.(*Searcher).docPointersInvertedNoFrequency.func1
 130.83MB  1.70% 98.58%   7594.13MB 98.91%  github.com/semi-technologies/weaviate/adapters/repos/db/inverted.(*Searcher).DocIDs
      1MB 0.013% 98.59%     40.55MB  0.53%  github.com/semi-technologies/weaviate/adapters/repos/vector/hnsw.(*hnsw).Add
        0     0% 98.59%     65.83MB  0.86%  github.com/go-openapi/runtime/middleware.NewOperationExecutor.func1

更新2：

升级到1.12.1后仍然存在问题。

Answer 1

由于您已经提到了它在大约20k记录下崩溃，所以不应该有运行OOM的理由。而且，在1M的记录中，16 so的内存应该足够了，所以我相信肯定还有另外一个原因可以让我们发现。

首先，我们需要一些关于您的设置的信息：

1. 你在运行哪种版本的Weaviate？在编写这个答案时，最新的版本是v1.12.1。请务必使用最新版本，以排除您遇到的任何问题已经解决。
2. 你在运行多少个--如果有的话--模块？这是相关的，因为模块中的模型占用了一定数量的内存。因此，在模块中模型的内存使用量为15,5GB的极端情况下，只剩下500‘d的内存留给Weaviate。这是不太可能的，但我们仍然应该排除一些确定的可能性。
3. 码头有什么限制吗？例如，Docker对Docker使用全局内存限制。可能低于全系统范围的限制？有什么限制吗？
4. 您提到您正在插入和查询。这不应该是一个问题，但更准确地了解您的用法可能会有所帮助。也许给出一个你运行的请求的例子，写读的比率等等。虽然这不太可能是任何问题的原因，但是任何其他信息都会有助于缩小这个范围。

分析

请用分析结果更新您的原始帖子。

为了调查内存问题，我们需要一些概要文件。我们可以从外部获取这些(操作系统看到了什么？)从内部( Go运行时看到了什么)。这两者之间通常是有区别的。这是因为GC释放的内存可能还没有被释放到操作系统。

侧写的准备工作

1. 在Weaviate容器上，将名为GODEBUG的环境变量设置为值gctrace=1。这将使Go的垃圾收集器冗长，并将任何GC活动记录到控制台。它会说当它运行时，堆在前后的样子，以及打印下一个目标大小。
2. 公开Weaviate容器的端口6060。这将允许从内部从Go的分析器生成调试报告。

剖面周期

1. 启动后立即(当API准备好时)，运行docker stats以打印整个停靠程序设置的内存的初始使用情况。这将帮助我们知道每个容器最初使用了多少内存。请把结果加到你的问题上。
2. 开始进口。
3. 在一定的时间间隔内(例如，如果您预期20k元素会崩溃，我将从导入的10k元素开始，每3k元素获取一次快照)，将以下命令的输出保存到单独的文件中

- `docker stats` so we see the OS' perspective
- The last three lines of the gc profile in the Weaviate container logs

你越接近那些配置文件崩溃的时刻，它们就越有意义。

1. (可选)如果前面的步骤确认堆确实完全用完了，例如接近16 on的堆使用量，那么有趣的问题是“堆是怎么这么早就用完的？”这个问题可以通过使用go pprof工具和我们前面公开的端口6060来回答。对于这个您需要安装本地Go运行时。。或者，如果您不想在主机上安装Go，可以从在具有Go运行时的docker容器中。运行这些命令。在这种情况下，请确保容器可以访问Weaviate容器，例如将它们放在同一个Docker网络中。从go运行时运行以下命令go tool pprof -top http://localhost:6060/debug/pprof/heap。类似于步骤3，您越接近于运行这个命令时，它就会有越多的意义。(请注意，我的示例假设您在主机上运行此操作，端口6060公开了Weaviate容器的端口6060。如果您在带有另一个容器的Docker网络中运行此操作，则相应地调整主机名，例如http://weaviate:6060/...等)

一旦您获得了所有这些配置文件，并编辑了您的原始文章与配置文件，我很高兴地编辑这篇文章与一些关于如何解释他们的笔记。

总之，您应该提供以下工件：

1. 导入前启动后的docker stats输出
2. 从接近崩溃点的那一刻起，我们需要
   • docker stats输出
   • GC的最后几行日志来自Weaviate容器

3. 如果(2)的结果确实证实了整个16 to被Weaviate消耗殆尽，那么我们需要知道的是什么。我们可以从pprof堆配置文件中获得此信息。