Optimisation Taille Index/Shard

[Thibaut Tropardy]

Bonjour à tous,

J'aurais voulu savoir comment estimer la taille de mon index.

Pour le moment, j'ai importer 14 944 129 documents. Pour le moment, mes données utilise 7.3gb (brute) et 15 gb avec les réplicats répartis 4 machines (lancement par défaut sans paramètrage JVM), en Java 7

A terme, je devrais avoir 140 millions de documents et donc un stockage estimé d'environ 70 G occupé. J'essaye d'estimer le nombre de noeuds que je devrais déployer une fois l'index complètement remplis, si je veux un passage en production. 

J'ai laissé le nombre de shards par défaut, 5 shards avec 1 réplicat

Pour le moment avec mes 14 millions de document, le moins que l'on puisse dire, c'est que ça rame déjà. Sur certaines requêtes, j'ai des problèmes de mémoire, qui font planter mes noeuds Elastic Search. J'ai essayé de redémarrer tous mes noeuds, d'optimiser mon index, de flusher, mais même résultat. 

Comme je sais que les facets utilisent de la mémoire, je les ai désactivé temporairement, et j'ai supprimé mes filtres, et critères de recherches. Même la requête la plus simple match All pour récupérer le nombre total de hits fait planter Elastic Search.

Ma question est donc simple, quel est selon vous la taille préconisé pour un shard? Existe-il un ratio taille occupé/nb shard couramment pratiqué, lou faut-il plutôt parlé en terme de nombre de documents?

D'avance merci.

[Benoît]

Bonjour,

Ça semble plutôt être un problème de mémoire que de taille d'index/shard.

J'ai un index de 4 shard d'environ 500 Go pour 67 millions de document et ça roule

Avec les log et BigDesk par exemple tu dois pouvoir te faire une idée.

Benoît

[Thibaut Tropardy]

Tu as mis des paramètres particuliers pour la JVM?

Je vais avoir 2 nouveaux serveurs virtuels demain qui seront plus véloce que mes actuels, qui effectivement sont peut-être un peu juste au niveau mémoire

Je connaissais pas encore BigDesk, ca a l'ai intéressant, je referais mes essais en l'utilisant demain.

Merci.

[David Pilato]

Il y a aussi paramedic qui est un plugin sympa.

--

David ;-)

Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs

--
--
---
Vous pouvez également poster et consulter les réponses en anglais sur le groupe Elasticsearch https://groups.google.com/group/elasticsearch
 
Si vous avez également posté votre question sur la mailing list elasti...@googlegroups.com, merci d'indiquer ici le lien vers cette discussion pour faciliter le suivi.
 
Twitter : @ElasticsearchFR https://twitter.com/#!/ElasticsearchFR
Site web (English) : http://www.elasticsearch.org/
 
---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Elasticsearch FR.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse elasticsearch-...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
 
 

[Benoît]

On Tuesday, March 12, 2013 2:06:14 PM UTC+1, Thibaut Tropardy wrote:

Tu as mis des paramètres particuliers pour la JVM?

Je suis sous Debian et donc utilise le .deb

Dans /etc/default/elasticsearch je configure ES_HEAP_SIZE à la moitié de la RAM disponible.
Dans /etc/elasticsearch/elasticsearch.yml je mets bootstrap.mlockall à true

Je vais avoir 2 nouveaux serveurs virtuels demain qui seront plus véloce que mes actuels, qui effectivement sont peut-être un peu juste au niveau mémoire

Je connaissais pas encore BigDesk, ca a l'ai intéressant, je referais mes essais en l'utilisant demain.

Je ne sais pas combien on de RAM tes machines, mais la moitié et la valeur recommandée.
Ensuite fait tes tests et surveille avec Bigdesk le "Heap Mem" "Used", les Cache evictions et l'activité du GC.

Benoît

[Thibaut Tropardy]

Je l'ai essayé celui-ci, et d'ailleurs, après quelques rafraîchissement de l'outil, j'ai constaté que les temps de réponses augmentait. Il faut préciser que je n'ai pas des PC très costaud (32 bits Dual core 3Ghz)

[Thibaut Tropardy]

Les 2 machines virtuels que j'aurais demain sont en 64 bits, avec Ubuntu. D'ailleurs quels est la mémoire vive que je dois demandais? 2 G ou plus?

[Olivier Girardot]

Si tu vas en dessous de 8Go perso, j'aurais tendance à considérer que c'est pas un serveur de production...

Surtout en Java.

Le 12 mars 2013 14:52, Thibaut Tropardy <ttro...@gmail.com> a écrit :

Les 2 machines virtuels que j'aurais demain sont en 64 bits, avec Ubuntu. D'ailleurs quels est la mémoire vive que je dois demandais? 2 G ou plus?

--

[Thibaut Tropardy]

Ok, donc, ça suppose bien de ne pas laisser les paramètres par défaut de la JVM.

Le serveur physique n'a que 16Go au total, sur lequel on peux créer des machines virtuel.

Quel est le bon compromis? Mieux vaut 4 serveur virtuels avec 2Go de Ram ou 2 serveurs virtuels à 4 Go de Ram par exemple? 

[Thibaut Tropardy]

Et est-ce qu'il peux y avoir un intérêt à mettre 2 elasticsearch de 4Go sur le même serveur? Pour répartir des shards plus petit

Je m'explique :

La répartition des requêtes d'Elastic Search ne fait aucune préférence en fonction de la puissance des machines. Avec une machine virtuelle de 8Go, je vais avoir un grosse inégalité avec mes 2 machines à 2 Go chacune.

Alors je me pose la question si le fait de mettre 2 elasticsearch sur mon gros serveur ne va pas mieux répartir la charge.

Autre point de réflexion

Après, je prévois aussi de créer plusieurs index avec des alias. Si j'ai des index disproportionné par rapport à d'autres, peux t-on envisager sur un même cluster, de répartir de favoriser certain noeud plus puissant pour un index plus gros. Je pense à voix haute là. ;-)

Benoit

Ok, donc, ça suppose bien de ne pas laisser les paramètres par défaut de la JVM.

Les paramètres par default d'Elasticsearch sont fait pour pouvoir expérimenter rapidement sur un poste de développement ou un serveur de tests, pas pour de la prod.  

Le serveur physique n'a que 16Go au total, sur lequel on peux créer des machines virtuel.

Quel est le bon compromis? Mieux vaut 4 serveur virtuels avec 2Go de Ram ou 2 serveurs virtuels à 4 Go de Ram par exemple? 

 

Je dirais 1 seule avec 8Go pour ES, le reste pour le cache système tu devrais pouvoir aller déjà loin :o)

Les autres pourrons confirmer mais il n'y a pas d'intérêt à faire un cluster avec des VM si toutes les VM sont sur la même machine physique. 
Elasticsearch est aussi exigeant en IO, surtout si il n'a pas assez de RAM.

[Jérôme Mainaud]

Si ton problème est d'avoir un cluster déstabilisé, il y a des options qui te permettent de définir des règles de possitionnement de tes shards sur le cluster.

Je n'ai pas utilisé ces fonctions, donc je ne t'en dirai pas plus mais tu peux regarder de ce côté. http://www.elasticsearch.org/guide/reference/modules/cluster.html

Si tu choisis l'option 1 machine à 16 Go (8Go pour la Heap) qui me semble la meilleur, vérifie cependant que le garbage collector gère bien les 8 Go sans faire de pauses trop longues.

Bonne soirée.

--
Jérôme Mainaud
jer...@mainaud.com

--