La configuration
Nous avons mis en place un cluster SolrCloud (version Solr 4.10.4) composé de 6 serveurs répartis sur 2 centres de données (3 sur chaque DC).SolrCloud disparaît après 15-20 minutes
Le cluster est configuré avec 3 fragments et un facteur de réplication de 2 et gère un cœur avec des documents de 45 Mo avec une moyenne d'environ 100 Go par fragment. Il y a 3 instances de Zookeeper régulant le cluster qui résident sur 3 des 6 serveurs (ceux du premier DC).
Le cœur réside sur un disque SSD 6Gb/s sur tous les fragments. Le temps de ping intra-DC est de l'ordre de 0,3 ms, tandis que celui de l'inter-DC est de l'ordre de 3 ms. Le cluster est configuré sur Tomcat 7.0.61 et Java 7 avec une mémoire allouée de 26 Go alors que chaque serveur dispose de 32 Go alors que chaque nœud est configuré pour contacter le zookeeper toutes les 30 secondes.
La configuration du cache pour chaque nœud Solr est la suivante
<filterCache class="solr.FastLRUCache"
size="40000"
initialSize="40000"
autowarmCount="0"/>
<queryResultCache class="solr.LRUCache"
size="50000"
initialSize="20000"
autowarmCount="0"/>
<documentCache class="solr.LRUCache"
size="2000000"
initialSize="2000000"
/>
<fieldValueCache class="solr.FastLRUCache"
size="8"
autowarmCount="8"
showItems="8" />
En plus de cela, nous avons une application API qui effectue certaines opérations de recherche que la plupart du temps ressemblent:
q=Fragmento+de+retablo+NOT+DATA_PROVIDER%3A%22CER.ES%3A+Red+Digital+de+Colecciones+de+museos+de+Espa%C3%B1a%22&
rows=12&start=0&
sort=score+desc&
timeAllowed=30000&fl=*%2Cscore&facet.mincount=1
Nous utilisons un ou tout au plus pour trier les paramètres (le second étant l'identifiant unique de notre schéma mais pas dans cet exemple).
Le problème
Notre API envoie environ 5-10 requêtes par seconde sur le cluster. Même ce nombre minimal de demandes submerge le cluster et les nœuds commencent à disparaître alors que beaucoup d'E/S de disque sont observées en même temps. Nous faisons un réchauffement manuel du cache pendant environ 10 minutes avant de mettre le core à la disposition de l'API et nous remarquons qu'après un certain temps (et avant le crash du cluster), le taux de succès sur les caches est de 1 pour tous les queryResultCache=0.67 et documentCache=0.9 , alors qu'aucune expulsion ne se produit non plus. La consommation de mémoire est d'environ 88%.
Toutes les idées sur ce qui peut se tromper ou sur ce que nous devrions cibler seront très appréciées.
Avez-vous vérifié vos journaux solr/de Zookeeper? Vous pouvez trouver des informations utiles là-bas. – Yann
Salut, j'ai vérifié les logs de solr et de zookeeper et il se plaint des délais d'attente de socket. Je cours également un certain nombre d'expériences avec différentes configurations et profilage, et il semble que GC entre et interrompt le groupe entier –