Почему Прометей потребляет так много памяти? - PullRequest
Новая
       26

Почему Прометей потребляет так много памяти?

0 голосов
/ 13 мая 2019

Я использую Prometheus 2.9.2 для мониторинга большого окружения узлов.В рамках тестирования максимальной шкалы Prometheus в нашей среде я смоделировал большое количество показателей в нашей тестовой среде.

Мой сервер управления имеет 16 ГБ ОЗУ и 100 ГБ дискового пространства.

Во времяПри масштабном тестировании я заметил, что процесс Prometheus потребляет все больше и больше памяти, пока процесс не завершится.

Я заметил, что каталог WAL быстро заполняется большим количеством файлов данных, в то время как использование памятиПрометей поднимается.

Сервер управления очищает свои узлы каждые 15 секунд, и все параметры хранилища установлены по умолчанию.

Я хотел бы знать, почему это происходит, и как / если это возможночтобы предотвратить сбой процесса.

Спасибо!

Ответы [ 2 ]

0 голосов
/ 25 июля 2019

Поскольку комбинация меток лежит на вашем бизнесе, комбинация и блоки могут быть неограниченными, нет способа решить проблему с памятью для текущего дизайна Prometheus !!!!Но я советую вам компактировать небольшие блоки в большие, что уменьшит количество блоков.

Огромное потребление памяти по двум причинам:

  1. prometheus tsdb имеет блок памяти, который называется: "голова", потому что голова хранит все серии в последние часы, она съест много памяти.
  2. каждый блок на диске также потребляет память, потому что каждый блок на диске имеет читателя индекса в памяти, к ужасу, все метки, сообщения и символы блока кэшируются в структуре чтения индекса, чем больше блоков на диске,чем больше памяти будет занято.

в 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
}
0 голосов
/ 15 мая 2019

Сбой из-за нехватки памяти обычно является результатом слишком тяжелого запроса. Это может быть установлено в одном из ваших правил. (это правило может даже работать на странице графана вместо самого Прометея)

Если у вас очень большое количество метрик, возможно, правило запрашивает их все. Быстрое решение состоит в том, чтобы точно указать, какие метрики запрашивать с помощью определенных меток вместо регулярных.

...