Org.elasticsearch.cluster.block.ClusterBlockException: blocked by: [SERVICE_UNAVAILABLE/2/no master];

Elastic In Your Native Tongue Discussions en français
1

Bonjour,

Assez souvent j'ai ce type d'erreur dans mes logs lors de l'insertion dans du ELS 1.7.

Est-ce une erreur réseau ou ceci pourrait il être causé par une saturation d'une des 2 machines de mon cluster ?

SERVICE_UNAVAILABLE/2/no master correspond il au premier noeud ?

2015-08-13 11:19:29,267 [standalone] [elasticsearch[Hero][liste] ERROR c.e.c.b.o.ElasticSearchUpdaterService - Error while index in ELS failure:[IdevElastic01][inet[/10.10.21.71:9300]][indices:data/write/bulk]
org.elasticsearch.transport.RemoteTransportException: [IdevElastic01][inet[/10.10.21.71:9300]][indices:data/write/bulk]
org.elasticsearch.cluster.block.ClusterBlockException: blocked by: [SERVICE_UNAVAILABLE/2/no master];
	at org.elasticsearch.cluster.block.ClusterBlocks.globalBlockedException(ClusterBlocks.java:151) ~[test-components-standalone-4.2.0-SNAPSHOT.jar:na]
	at org.elasticsearch.cluster.block.ClusterBlocks.globalBlockedRaiseException(ClusterBlocks.java:141) ~[test-components-standalone-4.2.0-SNAPSHOT.jar:na]

Merci d'avance,
Blured.

2

Le master node semble ne pas répondre donc le noeud data doit se bloquer...

Par curiosité, c'est quoi ça ? test-components-standalone-4.2.0-SNAPSHOT.jar

3

C'est je jar qui contient ma classe qui lance l'import des datas dans Elastic

4

J'ai des problèmes de GC en fait un node, les 2 sont éligibles en tant que master donc au final les indexes sont corrompus.

5

Ah oui. GC = pas bien !

6

Normalement il ne faudrait pas du tout qu'il y ait d'appel au GC dans les logs d'Elastic ?

Après avoir modifié la conf de mes serveurs et assigné 2 Go de RAM pour chacun je tombe rapidement sur des WARN de ce type
[2015-08-17 08:23:12,682][WARN ][monitor.jvm ] [IdevElastic02] [gc][old][4137][11] duration [32.2s], collections [1]/[32.6s], total [32.2s]/[2.1m], memory [1.9gb]->[1.9gb]/[1.9gb], all_pools {[young] [133.1mb]->[74.1mb]/[133.1mb]}{[survivor] [6.2mb]->[0b]/[16.6mb]}{[old] [1.8gb]->[1.8gb]/[1.8gb]}

...

Je vais vérifier mon code alors ...

7

Rapidement, au bout de 1 heure d'insert.

8

Normalement, tu ne devrais pas voir ce genre de WARN. Ca veut dire qu'il essaye de libérer de la mémoire mais qu'il n'y arrive pas vraiment ne fait.

Peut-être essayes-tu d'injecter trop de documents avec des requêtes gourmandes en RAM le tout avec seulement 2Gb de HEAP.

2Gb c'est bien pour des tests. En prod, c'est super léger à mon avis.

9

J'injecte des bulk de 5000 documents

je vais essayer avec 1000

10

Même tarif même punition avec des bulk de 1000 ou de 100.

Il y a environ 1 millions de documents au total.
Chaque document contient un code, un texte et un hash
Au max 1 Ko par document

Cette volumétrie est elle antinomique avec une machine possèdant 2Go de RAM ?

11

Ce qui est bizarre c'est que ceci ne se produit que sur FreeBSD
Sur ma machine de dev en windows qui possède aussi 2Go de RAM je n'ai pas de problème particulier.

Le delta c'est que sur FreeBSD c'est du OpenJDK1.7 et sur Windows du JDK 1.7 officiel d'Oracle.

OpenJDK est il certifié avec Elastic ?

12

Oui mais ça dépend de la version exacte: https://www.elastic.co/subscriptions/matrix

En tout cas, je ne pense pas que ce soit vraiment le problème ici.
Peut-être que le GC Oracle et celui de OpenJDK se comportent différemment ?

Tu ne fais que de l'indexation ? Sans aucune recherche ?

13

Je suis en OpenJDK1.7_80-b15 sur FreeBsd.

Je ne fais que de l'indexation sans recherche.

Le deuxième delta est que j'ai 2 serveurs FreeBsd en cluster et que sur ma machine de dev il n'y a qu'un serveur.

J'ai relancé pour voir sur un seul serveur Free pour voir si le problème ne vient pas du cluster;

14

Étonnant si j'utilise juste un serveur Elastic, tout fonctionne correctement je n'ai pas d'erreur de GC ou de saturation de la Heap.

Le fait de mettre un serveur en plus dans le cluster d'elastic a t il un impact sur l'occupation mémoire ?

15

Oui si tu as le nombre de replica = 1 (valeur par défaut), tu transmets du coup les bulks deux fois.
Pour initialiser un index, idéalement tu mets le nb de replica à 0 puis après indexation tu passes à 1.

Ca évite de faire deux fois les opérations d'indexation. Dans ce cas, elasticsearch n'a plus qu'à copier les fichiers depuis un noeud vers l'autre.

16

Ok je vais essayer comme ça.

Concernant la volumétrie j'ai des chiffres plus précis :

Indexes	        Nombre docs    Taille sur disque (MB)
labels-bg	8 405	       2,20
labels-fr	302 833	       210,70
metadatas	3	       0,00
labels-sl	8 005	       3,70
labels-pl	140 677	       126,10
labels-et	8 522	       8,30
labels-no	8 035	       3,90
labels-nl	157 666	       92,20
labels-es	172 788	       80,60
labels-fi	85 546	       118,50
labels-ru	144 544	       53,60
labels-pt	157 033	       64,30
labels-zh	66 308	       16,10
labels-ro	8 314	       2,50
labels-zz	2 999 497      1003,00
labels-de	215 376	       207,20
labels-tu	140 379	       52,80
labels-en	76 239	       588,00
labels-gr	138 802	       54,40
labels-it	491 375	       131,30
labels-hu	8 077	       2,40
labels-cs	8 126	       2,10
labels-se	135 449	       93,10
labels-zs	132 554	       39,20
labels-dk	136 294	       88,70
labels-lt	8 854	       5,90
labels-ar	114 736	       93,70
labels-lv	8 129	       3,70
		
Total           5 882 566      3148,20
17

Zut, j'ai encore le GC qui s'excite dans le cas de 2 serveurs même avec un nombre de replica à 0 pour chacun des indexes

Pour idevElastic01

[2015-08-18 09:22:44,243][WARN ][monitor.jvm              ] [IdevElastic01] [gc][young][74239][27537] duration [8.2s], collections [1]/[9.9s], total [8.2s]/[14.5m], memory [900.5mb]->[787mb]/[1.9gb], all_pools {[young] [119.2mb]->[2.1mb]/[133.1mb]}{[survivor] [1.5mb]->[5mb]/[16.6mb]}{[old] [779.6mb]->[779.7mb]/[1.8gb]}

Pour idevElastic02

[2015-08-18 09:21:38,447][INFO ][monitor.jvm              ] [IdevElastic02] [gc][young][2667][1632] duration [898ms], collections [1]/[1.3s], total [898ms]/[59.6s], memory [1006.3mb]->[1gb]/[1.9gb], all_pools {[young] [16.6kb]->[4.1kb]/[133.1mb]}{[survivor] [16.6mb]->[16.6mb]/[16.6mb]}{[old] [989.7mb]->[1gb]/[1.8gb]}
[2015-08-18 09:21:39,598][INFO ][monitor.jvm              ] [IdevElastic02] [gc][young][2668][1633] duration [825ms], collections [1]/[1.1s], total [825ms]/[1m], memory [1gb]->[1gb]/[1.9gb], all_pools {[young] [4.1kb]->[10.4kb]/[133.1mb]}{[survivor] [16.6mb]->[16.6mb]/[16.6mb]}{[old] [1gb]->[1gb]/[1.8gb]}
[2015-08-18 09:21:43,365][WARN ][monitor.jvm              ] [IdevElastic02] [gc][young][2669][1634] duration [3.3s], collections [1]/[3.7s], total [3.3s]/[1m], memory [1gb]->[1gb]/[1.9gb], all_pools {[young] [10.4kb]->[4.1kb]/[133.1mb]}{[survivor] [16.6mb]->[16.6mb]/[16.6mb]}{[old] [1gb]->[1gb]/[1.8gb]}
[2015-08-18 09:22:05,431][WARN ][monitor.jvm              ] [IdevElastic02] [gc][young][2683][1644] duration [7.3s], collections [1]/[7.8s], total [7.3s]/[1.2m], memory [1.5gb]->[1.5gb]/[1.9gb], all_pools {[young] [122mb]->[1.3mb]/[133.1mb]}{[survivor] [3.6mb]->[4.6mb]/[16.6mb]}{[old] [1.4gb]->[1.5gb]/[1.8gb]}
18

Tu as beaucoup d'index !
Avec si peu de mémoire...

Combien de shard par index?

19

1 shard par index

20

Pourquoi tant d'index ? Ils semblent avoir le "même" rôle quelque part.

Pourquoi pas un seul index labels avec éventuellement des types différents?