Tools zum Suchen von solr-Leistungsproblemen

Wenn Sie nach einer langfristigen Überwachung suchen, können Sie auch Tools und Dienste wie Scalable Performance Monitoring (SPM) von meiner Firma, Sematext oder anderen, betrachten. Ссылка

Dieser Service zeigt Anfrageraten, Latenz, alle Solr-Cache-Informationen, JVM-Speicher, GC, CPU, Auslastung, Festplatten- und Netzwerk-IO usw. an.

Wir essen unser eigenes Hundefutter und verwenden dieses Tool, um die Solr-Instanzen hinter search-lucene.com und search-hadoop.com/ zu überwachen. Wir verwenden es regelmäßig mit unseren Kunden, wenn wir ihnen bei der Solr-Leistung helfen müssen tuning.

Wenn Sie keine "ordnungsgemäße" Leistungsüberwachung a la oben wünschen, können Sie Tools wie vmstat, iostat, sar, top, jstack usw. zur Fehlerbehebung bei der Solr-Leistung verwenden, vorausgesetzt, Sie führen es unter UNIX aus.

Ich denke, Sie sollten mit der Solr-Leistungsfaktoren im Solr-Wiki beginnen. Sie können auch das Tool SolrMeter verwenden, um beim Stresstest Ihrer Änderungen zu helfen.

Das Dienstprogramm 'sar' aus dem sysstat-Paket eignet sich hervorragend zum Debuggen von Problemen mit der Datenträger-E / A. Wenn Sie feststellen, dass ein bestimmter Datenträger mehr als 30% oder mehr konsistent genutzt wird, sind Sie wahrscheinlich an IO gebunden.

Vielleicht kann dir dieses Tool helfen: LucidGaze . LucidGaze .

Ich habe keine Erfahrung damit, aber es sieht vielversprechend aus. Die Leute von Lucid haben auch einige interessante Artikel veröffentlicht, die wirklich lesenswert sind.

Ich habe einen Stresstest der Anwendung durchgeführt, indem ich mehrere Anfragen gleichzeitig an den Server gesendet habe (Anfragen wurden von nachfolgenden wgets gestellt)

Wir haben begonnen, die Auswirkungen auf die Leistung zu sehen und unser Problem auf zwei Ursachen zu beschränken:

• Die Cachegröße war zu klein, daher gab es zu viele Räumungen und Einfügungen im Cache.
• Wir haben solrversion1.3 verwendet, das offensichtlich blockierende Lesevorgänge für die Indexdateien verwendet. Die Umstellung auf solr 1.4 hat dieses Problem beseitigt, da es java nio verwendet, das nicht blockierende Lesevorgänge von Indexdateien verwendet.

[wir haben auch versucht, die Indexdateien in ram zu schreiben und direkt von dort zu verwenden, was die Performance verbessert (aber offensichtlich nicht skalierbar ist)]

Ich habe SOLR-Speicherlecks über ein Jahr lang erfahren und musste den Server fünf Tage lang als Workaround für das Problem verwenden. Schließlich stellte ich fest, dass das Überwachungstool RELIC das Problem verursachte. Wir entfernten die Überwachung und das Problem wurde gelöst, daher ist mein Ratschlag, vorsichtig zu sein, wenn zu viele Monittoring-Tools verwendet werden, es bringt einen Overhead für die Leistung.