Question

我正在使用Prometheus 2.9.2监视大型节点环境。在测试环境中Prometheus的最大规模时，我在测试环境中模拟了大量指标。

我的管理服务器具有16GB内存和100GB磁盘空间。

在规模测试期间-我注意到Prometheus进程消耗越来越多的内存，直到该进程崩溃为止。

我注意到WAL目录正在快速填充大量数据文件，而Prometheus的内存使用量却在增加。

管理服务器每15秒刮一次其节点，并且存储参数都设置为默认值。

我想知道为什么会这样，以及如何/是否有可能防止进程崩溃。

谢谢！

Answer 1

内存不足崩溃通常是由于查询过于繁重导致的。这可以在您的规则之一中设置。（此规则甚至可能在grafana页面上运行，而不是在prometheus本身上运行）

如果您有大量指标，则规则可能会查询所有指标。一种快速的解决方法是，确切指定要使用特定标签而不是正则表达式查询的指标。

Answer 2

由于标签的组合取决于您的业务，因此组合和块可能是无限的，因此无法解决当前普罗米修斯设计中的存储问题！但是我建议您将小块压缩为大块，这样可以减少块的数量。

两个原因导致的大量内存消耗：

prometheus tsdb有一个名为“ head”的内存块，因为head在最近几个小时存储了所有系列，因此它将占用大量内存。
磁盘上的每个块也占用内存，因为磁盘上的每个块在内存中都有一个索引读取器，令人沮丧的是，一个块的所有标签，发布和符号都缓存在索引读取器结构中，磁盘上的块越多，内存就越大会很累。

在index / index.go中，您将看到：

type Reader struct {
    b ByteSlice

    // Close that releases the underlying resources of the byte slice.
    c io.Closer

    // Cached hashmaps of section offsets.
    labels map[string]uint64
    // LabelName to LabelValue to offset map.
    postings map[string]map[string]uint64
    // Cache of read symbols. Strings that are returned when reading from the
    // block are always backed by true strings held in here rather than
    // strings that are backed by byte slices from the mmap'd index file. This
    // prevents memory faults when applications work with read symbols after
    // the block has been unmapped. The older format has sparse indexes so a map
    // must be used, but the new format is not so we can use a slice.
    symbolsV1        map[uint32]string
    symbolsV2        []string
    symbolsTableSize uint64

    dec *Decoder

    version int
}

Answer 3

我们使用了 prometheus 2.19 版，我们的内存性能明显更好。 This Blog highlights how this release tackles memory problems。我强烈建议使用它来改善您的实例资源消耗。

Answer 4

This article 解释了为什么 Prometheus 在数据摄取期间可能会使用大量内存。如果您需要减少 Prometheus 的内存使用量，那么以下操作会有所帮助：

在 Prometheus configs 中增加 scrape_interval。
减少抓取目标的数量和/或每个目标抓取的指标。

附言也看看我从事的项目 - VictoriaMetrics。与 Prometheus 相比，它可以使用更少的内存。有关详细信息，请参阅 this benchmark。

为什么普罗米修斯会消耗这么多内存？

4 个答案: