Schätzung von Arbeitsspeicher und Speicherplatz für Lucene/Solr

Oft werden wir von Kunden gebeten, ihnen bei der Schätzung der Speicher- oder Festplattenplatznutzung zu helfen oder Benchmarks zu veröffentlichen,…

Oft werden wir von Kunden gebeten, ihnen bei der Schätzung der Speicher- oder Festplattenplatznutzung zu helfen oder Benchmarks zu veröffentlichen, während sie ihr Suchsystem aufbauen. Dies ist immer ein interessanter Prozess, denn ich war schon immer misstrauisch gegenüber Behauptungen über Benchmarks (einer der alten Tricks beim Hacken von Performance-Benchmarks ist z.B. „cat XXX > /dev/null“, um alles zuerst in den Speicher zu laden, was die meisten Leute nicht tun, wenn sie ihr System laufen lassen) oder Schätzungen, weil ich weiß, dass so viele Variablen beteiligt sind, dass die Ergebnisse je nach Marketingzielen ganz erheblich variieren können.

Daher neige ich dazu, pragmatisch zu sein (was meiner Meinung nach auch die Lucene/Solr-Gemeinschaft tut) und mich darauf zu konzentrieren, was meine Tests für meine spezifischen Daten und meine spezifischen Anwendungsfälle zeigen. Um beispielsweise den Speicher zu testen, ist es ziemlich einfach, eine Reihe von Tests zu erstellen, die mit einer kleinen Heap-Größe beginnen und diese sukzessive erhöhen, bis keine Out Of Memory Errors (OOME) auftreten. Um auf Nummer sicher zu gehen, fügen Sie dem Heap dann 1 GB Speicher hinzu. Das funktioniert bei der großen Mehrheit der Benutzer.

Ironischerweise endet dies zumindest bei Solr in der Regel mit einer Heap-Größe zwischen 6 und 12 GB für ein System, das eine „Verbrauchersuche“ mit Facettierung usw. durchführt und einen Index mit einer vernünftigen Größe von 10 bis 50 Millionen Dokumenten im Cache hat. Sicherlich gibt es Systeme, die darüber hinausgehen oder deutlich kleiner sind (ich habe neulich ein System gesehen, das etwa 200 Millionen Dokumente in weniger als 3 GB RAM gespeichert hat und gleichzeitig eine ordentliche Suchlast bewältigt), aber die 6-12 GB scheinen ein guter Sweet Spot für die Anwendung und die JVM zu sein, vor allem wenn es um die Garbage Collection geht, während das Betriebssystem noch genug Platz hat, um seine Arbeit zu erledigen. Wenn Sie zu viel Heap haben, kann es sein, dass sich Müll ansammelt und Sie irgendwann in der Zukunft volle Garbage Collections bekommen. Zu wenig Heap und Sie bekommen das gefürchtete OOME. Auch zu viel Heap im Verhältnis zum gesamten Arbeitsspeicher führt dazu, dass Sie das Betriebssystem abwürgen. Außerdem hat dieser Bereich auch einen netten geschäftlichen/operativen Nebeneffekt, denn 16 GB RAM sind für viele Menschen ein netter Leistungs-/Kostenvorteil.

Kürzlich dachte ich jedoch, dass es gut wäre, über das oben erwähnte Winken mit der Hand hinauszugehen und zu versuchen, ein theoretisches Modell (mit einer kleinen Prise Empirie) für die Abschätzung der Speichernutzung und des Festplattenplatzes zu entwickeln. Nach einigen Diskussionen im IRC mit McCandless und anderen habe ich eine ENTWURFENE Excel-Tabelle erstellt, mit der man sowohl den Speicher- als auch den Festplattenspeicherplatz modellieren kann (basierend auf der Formel in Lucene in Action 2nd ed. – LIA2), nachdem man einige Annahmen über seine Anwendungen eingegeben hat (ich habe Standardwerte eingegeben.) Zunächst ein paar Vorbehalte:

1. Dies ist nur eine Schätzung, interpretieren Sie sie nicht als das, was Sie tatsächlich in Ihrem System sehen.
2. Es ist ein ENTWURF. Wahrscheinlich fehlen noch ein paar Dinge, aber ich stelle ihn hier und in Subversion zur Verfügung, um Feedback zu erhalten. Ich behalte mir das Recht vor, die Berechnungen vermasselt zu haben.
3. Ich habe das Gefühl, dass die Werte für den Speicherschätzer etwas zu niedrig sind, insbesondere für den Lucene-Abschnitt.
4. Es ist nur für den Kofferraum geeignet. Ich glaube nicht, dass es für 3.3 oder 3.4 geeignet ist.
5. Das Ziel ist es, ein Modell für die „Hochwassermarke“ von Arbeitsspeicher und Festplatte zu erstellen, nicht unbedingt den typischen Fall.
6. Es setzt voraus, dass Sie auf demselben Rechner suchen und indizieren, was oft nicht der Fall ist.
7. Es gibt noch ein paar TODOs im Modell. Mehr dazu später.

Was die Verwendung des Speicherschätzers betrifft, so müssen Sie vor allem die Anzahl der Dokumente, die Anzahl der eindeutigen Begriffe und die Informationen über die Sortierung und die indizierten Felder eingeben, aber Sie können auch mit allen anderen Annahmen herumspielen. Für Solr gibt es Einträge zur Schätzung des Cache-Speicherverbrauchs. Denken Sie daran, dass beim Caching davon ausgegangen wird, dass die Caches voll sind, was oft nicht der Fall ist und auch nicht möglich ist. Ihr System verwendet zum Beispiel vielleicht nur 5 oder 6 verschiedene Filter. Die Schätzung des Festplattenspeichers ist viel einfacher und basiert auf der recht einfachen Formel von LIA2:

belegter Speicherplatz (Original) = 1/3 Original für jedes indizierte Feld + 1 * Original für gespeicherte Felder + 2 * Original pro Feld mit Termvektoren

Es wird interessant sein zu sehen, wie sich einige der neuen flexiblen Indizierungsfunktionen in Trunk auf die Ergebnisse dieser Gleichung auswirken. Beachten Sie auch, dass ich einige Anwendungen gesehen habe, bei denen die Größe der indizierten Felder nur 20% beträgt. Ich hoffe, dass die Leute das Programm nützlich finden, es verbessern und eventuelle Fehler beheben. Mit anderen Worten: Feedback ist willkommen. Wie bei jedem Modell dieser Art gilt: YMMV!