Paramètres recommandés pour NiFi et Elasticsearch
Vous pouvez exécuter vos environnements Elasticsearch et NiFi à l'aide des paramètres par défaut, ce qui fournit un ensemble de ressources minimal. Pour de meilleures performances, paramétez votre configuration ou utilisez les paramètres recommandés pour l'UC, la mémoire et les ressources système.
Ressources système, encombrement de mémoire et allocation d'UC pour Elasticsearch et NiFi
L'environnement recommandé (ou minimal) se compose de plusieurs nœuds qui hébergent les pods Elasticsearch et NiFi. Après une installation initiale, le système dispose par défaut de trois pods Elasticsearch Kubernetes et d'un pod NiFi. Chaque pod est un groupe de conteneurs Docker avec des espaces de noms partagés et des volumes de système de fichiers partagés.
La configuration minimale de chaque pod inclut 6 vCPU et 10 Go de RAM. Dans la configuration recommandée, chacun des pods a accès à 16 processeurs virtuels et à au moins 16 Go d'espace de segment de mémoire.
Il est possible que certaines ressources doivent être ajustées ou surexploitées. Si c'est le cas, des tests supplémentaires pour confirmer la configuration seront nécessaires pour assurer la stabilité et l'opérabilité.
| Pods | Pod vCPU/Elasticsearch | Pod vCPU/NiFi | Segment de mémoire Elasticsearch | Segment de mémoire NiFi | |
|---|---|---|---|---|---|
| Configuration minimale (par défaut) |
3 - Elasticsearch 1- NiFi |
6 | 6 | 12 | 9 |
| Configuration recommandée |
3 - Elasticsearch 1- NiFi |
16 | 16 | 16 | 12 |
NiFi
Le débit obtenu dans le cluster NiFi/Elasticsearch détermine la vitesse à laquelle les données sont traitées et les index sont créés. Les threads de processeur NiFi et la taille du compartiment sont deux facteurs qui peuvent augmenter et optimiser les performances pour un encombrement matériel donné.
Forums
Dans NiFi, chaque processeur a la capacité de traiter les flowfiles en mode parallèle. Pour ce faire, allouez plus de threads à l'UC ou augmentez la variable de travaux simultanés à plus de 1. Le processeur NLP dans l'instantané suivant est configuré sur 16 tâches simultanées, ce qui correspond au nombre de vCPU disponibles sur le nœud.
Le débit du processeur sera amélioré en augmentant les threads sur l'UC. Des threads supplémentaires augmenteraient la bande passante du processeur par le facteur du nombre de threads, si le processeur fait un traitement computationnel (c'est-à-dire que nous pouvons faire l'expérience d'une mise à l'échelle linéaire).
En cas d'opérations d'E-S, le processeur va subir une amélioration qui commencerait à diminuer une fois qu'un certain niveau de threads est défini (ex. : une évolutivité non linéaire qui se terminerait par une saturation).
Taille du compartiment
Une autre option qui peut être modifiée pour augmenter la bande passante du processeur est la taille du compartiment (scroll.bucket.size). En augmentant la taille du compartiment, vous augmentez la quantité du bloc de données qui sera traitée par un processeur unique en tant que groupe.
Le nom de variable des changements de taille de compartiment n'est pas immédiatement évident. A partir de HCL Commerce version 9.1.6, vous pouvez le trouver dans le deuxième niveau du groupe de processeurs.
- Le niveau supérieur ressemble à ceci :
- A un niveau inférieur, cliquez avec le bouton droit de la souris et choisissez "variables":
- Ensuite, modifiez la valeur de la taille du compartiment :
Elasticsearch
Taux d'actualisation des indices
Elasticsearch actualise les indices toutes les secondes par défaut, mais uniquement sur les indices qui ont eu une ou plusieurs demandes de recherche au cours des trente dernières secondes. Cette période est définie sur dix secondes par défaut par le schéma d'index de commerce. Toutefois, si cela est viable, désactivez-la et définissez la période sur -1 ou sur une durée bien plus longue (par exemple, sur un intervalle d'actualisation de 60 secondes).
Pour configurer une valeur personnalisée, suivez le flux de travaux
Indexation des tailles de la mémoire tampon
L'indexation des tailles de mémoire tampon permettra d'accélérer l'opération d'indexation et l'augmentation de leur taille améliorera la vitesse de génération globale de l'index. La valeur est définie dans indices.memory.index_buffer_size variable et est généralement définie sur 10 % de la taille du segment de mémoire OTB.
Il est conseillé de la définir plus haut, à 20 % de la taille du segment de mémoire.
Pour plus d'informations sur les intervalles d'actualisation d'indexation Elasticsearch, voir le guide Elasticsearch.