ChronicleMap verursacht JVM zum Absturz, wenn die Werte in Größe sehr variabel sind

Question

Wir hatten bisher Erfolg ChronicleMap für die meisten Dinge, die wir verwenden wollten, und die meisten Datensätze haben gut funktioniert. Ein Anwendungsfall, den wir verwenden, verwendet es als Multimap und deckt damit die meisten Bedenken ab. Wir verwenden es speziell in diesem Fall als Map<String,Set<Integer>>. Wir sind jedoch auf einige interessante JVM-Abstürze gestoßen und haben Probleme, ein deterministisches Muster zu finden, um sie zu vermeiden.

Also, bevor wir alle Set<Integer> in ChronicleMap setzen, haben wir es vollständig in der JVM, also schreiben wir sofort, um die Fragmentierung zu reduzieren. Da wir es vollständig im Speicher haben, können wir bestimmen, was die maximale und durchschnittliche Größe Set<Integer> ist, und können die ChronicleMap mit ChronicleMapBuilder.averageValueSize geeignet Größe. In den meisten Fällen funktioniert das gut.

In einigen Fällen jedoch stürzt die JVM ab, wenn die Größe der Set<Integer> weit vom Durchschnitt abweicht. Zum Beispiel könnte die durchschnittliche Größe 400 betragen, aber wir könnten Ausreißer-Sets mit 20.000 ganzen Zahlen haben. Wir können die Karte immer noch mit der durchschnittlichen serialisierten Größe eines Satzes von 400 ganzen Zahlen sortieren, und sie fängt an, ChronicleMap in Ordnung zu füllen, bis sie eine sehr große Liste erreicht.

Also die Frage ist: Wie finde ich heraus, wie groß ich vom Durchschnitt abweichen kann? Ich hatte gehofft, dass der Durchschnitt in der Tat ein Durchschnitt war, aber es scheint einige Max zu geben, die dazu führen, dass die JVM stirbt.

Wir entwickelten einen Algorithmus, um die großen Sätze in kleinere Sätze aufzuteilen (z. B. wenn der Schlüssel AAA war, dann gibt es jetzt Schlüssel AAA: 1, AAA: 2, ... AAA: n). Die Größe des Split-Sets war 10-mal so groß wie die Durchschnittsgröße. Mit anderen Worten, wenn die Durchschnittsgröße 500 war, aber wir hatten eine Menge von 20.000, teilten wir sie in vier 5.000 (500 * 10) Elementmengen auf.

Dies funktionierte in den meisten Fällen, aber dann stießen wir auf einen weiteren merkwürdigen Fall und selbst diese Aufteilung war nicht ausreichend. Ich habe den Faktor auf das 5-fache der Durchschnittsgröße reduziert und jetzt funktioniert es wieder ... aber woher weiß ich, dass das klein genug ist? Ich denke, das Quellproblem zu wissen oder genau zu bestimmen, was es verursacht, ist der beste Weg, aber leider habe ich keine Ahnung, warum ChronicleMap hier kämpft.

Auch, FWIW, ich benutze eine ältere Version 2.1.17. Wenn dies ein Fehler ist, der in einer neueren Version behoben wurde, würde ich gerne ein kleines Detail über den Fehler wissen und wenn wir es mit unseren eigenen Mitteln vermeiden könnten (wie das Teilen der Sets), aber weiterhin 2.1.17 benutzen (wir werde später aufrüsten, will das Boot nicht zu sehr rocken.

Answer 1

Ich kann nicht 100% sicher sein, ohne den Fehler zu reproduzieren, aber ich habe eine Idee, warum JVM Abstürze in diesem Fall auftreten. Wenn ich recht habe, passiert es, wenn deine Eintragsgröße 64 * chunkSize der Chronikkarte überschreitet. Chunk-Größe könnte direkt konfiguriert werden, aber wenn Sie nur durchschnittliche Schlüssel- und Wertgrößen konfigurieren, wird standardmäßig eine solche Zweierpotenz verwendet, dh zwischen averageEntrySize/8 und averageEntrySize/4, wobei die durchschnittliche Eintragsgröße die Summe aus durchschnittlicherKeySize und averageValueSize ist , zuzüglich einiger interner Kosten. In Ihrem Fall ist es wahrscheinlich, dass wenn Sie Durchschnittswerte haben - Sätze von 400 oder 500 Ints (je 4 Bytes), + kleine Schlüssel, nehme ich an, dass chunkSize als 256 Byte berechnet wird, also sollten Ihre Einträge kleiner als 256 * 64 sein = 16384 Bytes.

Wiederum, wenn ich richtig in meiner Hypotesis bin, woher dieser Fehler kommt, sollte Chronicle Map 3 diesen Fehler nicht haben und sollte Einträge erlauben, die willkürlich größer als die durchschnittliche Größe oder Chunk-Größe sind.