Problème de mémoire

Bonjour,

J'ai un cluster de 7 nodes (3 master , 4 data) . Les master sont des vm et les data des machines physiques (48 cpu, 64Go ram et 24To disque par machine)

On ramene un peu de tout dans le cluster (logs applicatifs, firewall, exchange , proxy etc...)

Le volume conséquent vient des firewall puis nous avons plus de 100 index avec 200Go par index (tous encore ouverts).

NB : étrangement, on a définit 100Go dans l'ILM pour les firewall mais l'index fait à chaque fois 200Go

On commence bien sur à avoir des problemes de mémoire malgré les jvm des data nodes a 30Go chacune. On a fréquemment des breaker circuit qu'on voit dans le monitoring avec Prometheus.

Mes questions :

  1. le fait de fermer les index va-t-il réduire considérablement le heap usage ?
  2. est-ce que plus l'index est grand, plus il prend de la place en mémoire ? Ou c'est juste un pointeur, peu importe la taille ?
  3. est-ce que le nombre de data nodes est suffisant ? On compte ajouter 2 cold nodes . On fermerait les index et on les bougerait dessus

Merci

Combien de shard avez vous par index ?

=> Il me semble que la consommation de la memoire est dependante au nombre des index et aussi la taille des shards.

=> 3 masters. Master elligible. Lors du lancement seulement, 1 sera élu master. Donc les 2 autres font rien. Pourquoi ne pas les faire travailler ? Pk ne pas avoir 3 master elligible et data + les 4 autres data.

Bonjour,

On est parti sur 1 shard primaire et 1 replica .

Concernant nos masters, il n y a aucun storage sur ceux-ci. Donc on ne pourra pas les transformer en data node.

Merci

==> Il n'y a réellement pas de limite à la taille des shards. Mais il est qu'à même conseillé de limiter la taille des shards à 40 - 50 Go car la vitesse à laquelle ES déplacer les shards lors d'un réequilibrage de donnée dépends de la taille des shards / performance des DB. Plus les shards sont lourdes = +necessite de beaucoup de ressources.

Je pense que ce webinar pourrait vous apporter des solutions : https://www.elastic.co/fr/elasticon/conf/2016/sf/quantitative-cluster-sizing

Bonjour

Je me demande si cette taille ne correspond pas en fait à la taille totale (incluant les replicas).

Oui.

Un index plus grand va utiliser un peu plus de HEAP à cause du stockage _id et _uid en HEAP notamment.

Comme tu as des index temporels, c'est toujours bien je trouve de décharger les noeuds "hot" sur des noeuds "warms".

Lorsque le cluster commence à être gros (en nombre d'index et/ou de noeuds), avoir des noeuds master dédiés est plutôt une bonne idée car le cluster state (CS) commence à prendre pas mal de place. Faire les mises à jour du CS sur des machines non perturbées par la charge d'indexation est du coup la garantie d'une MAJ plus rapide.

Oui. En général on recommande des tailles par shard entre 20 et 50go suivant les tests.
Pas plus de 20 shards par Go de HEAP. Dans ton cas, sachant que tu as 3 noeuds à 30go de HEAP, pas plus de 600 shards par noeud, soit 1800 shards pour ton cluster.
Comme tu as 1 replica par shard, ça veut dire pas plus de 900 index sur ton cluster.

:+1:t3:

Merci pour vos réponses

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.