web-dev-qa-db-fra.com

Pourquoi Prométhée consomme-t-il autant de mémoire?

J'utilise Prometheus 2.9.2 pour surveiller un grand environnement de nœuds. Dans le cadre du test de l'échelle maximale de Prometheus dans notre environnement, j'ai simulé une grande quantité de métriques sur notre environnement de test.

Mon serveur de gestion a 16 Go de RAM et 100 Go d'espace disque.

Pendant les tests à l'échelle, j'ai remarqué que le processus Prometheus consomme de plus en plus de mémoire jusqu'à ce que le processus se bloque.

J'ai remarqué que le répertoire WAL se remplit rapidement avec beaucoup de fichiers de données tandis que l'utilisation de la mémoire de Prometheus augmente.

Le serveur de gestion élimine ses nœuds toutes les 15 secondes et les paramètres de stockage sont tous définis par défaut.

Je voudrais savoir pourquoi cela se produit et comment/s'il est possible d'empêcher le processus de planter.

Je vous remercie!

memoryprometheus
3
Thomason

Le crash de mémoire insuffisante est généralement le résultat d'une requête excessivement lourde. Cela peut être défini dans l'une de vos règles. (cette règle peut même s'exécuter sur une page grafana au lieu de prometheus lui-même)

Si vous disposez d'un très grand nombre de mesures, il est possible que la règle les interroge toutes. Une solution rapide consiste à spécifier exactement les métriques sur lesquelles interroger avec des étiquettes spécifiques au lieu d'une expression régulière.

1
Sutirtha Das

Parce que la combinaison d'étiquettes repose sur votre entreprise, la combinaison et les blocs peuvent être illimités, il n'y a aucun moyen de résoudre le problème de mémoire pour la conception actuelle de prometheus !!!! Mais je vous suggère de compacter de petits blocs en gros, ce qui réduira la quantité de blocs.

Grande consommation de mémoire pour DEUX raisons:

  1. prometheus tsdb a un bloc de mémoire qui s'appelle: "head", car head stocke toutes les séries dans les dernières heures, il va manger beaucoup de mémoire.
  2. chaque bloc sur le disque mange également de la mémoire, car chaque bloc sur le disque a un lecteur d'index en mémoire, consternant, toutes les étiquettes, publications et symboles d'un bloc sont mis en cache dans la structure du lecteur d'index, plus il y a de blocs sur le disque, plus la mémoire sera occupée .

dans index/index.go, vous verrez:

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
chausat