Dimensionierung
Die Frage vor jeder Installation ist, wie viel Blech es braucht. Diese Seite beantwortet sie mit Messwerten einer Referenzanlage statt mit Faustregeln — und sagt dazu, was dabei nicht gemessen wurde.
Auf dieser Seite
Woher die Zahlen stammen
Zwei Messungen. Die Belastungsprobe vom 6. September 2026 lief auf einer einzelnen virtuellen Maschine: 6 vCPU, 24 GB Arbeitsspeicher, kein Swap, die vollständige Plattform darauf, Datengrundlage eine Faktentabelle mit 60 Millionen Zeilen, alle Szenarien über die abgesicherte Schnittstelle mit Anmeldung, Rechteprüfung und Audit. Der Lasttest vom 26. September 2026 hat dieselbe Maschinenklasse um einen Worker auf einer zweiten Maschine ergänzt und mit TPC-H gemessen, dem Standard-Test für Auswertungen.
Was eine Maschine dieser Klasse trägt
| Gleichzeitige Nutzer | Art der Last | Gemessen |
|---|---|---|
| bis 32 | Schwere Analysen über 60 Mio. Zeilen | Alle Abfragen fehlerfrei, keine Abweisung |
| 50 | Nur schwere Scans, 90 s | 124 fertige Analysen, keine Abweisung, p90 57 s |
| 64 | Schwere Analysen | 77 fertig, Median 53 s, darüber Abweisung |
| 32 | Kurze Abfragen im Dauerfeuer | 3.176 Abfragen in 60 s, Median 0,59 s |
Der Massenimport der 60 Millionen Zeilen lief in 73 Sekunden durch, also über 800.000 Zeilen je Sekunde. Über alle Läufe hinweg gab es keinen Absturz; dreißig Sekunden nach der härtesten Laststufe antwortete dieselbe Anlage in 76 Millisekunden.
Die Aufteilung des Arbeitsspeichers
Die wichtigste Einstellung ist, wie viel Arbeitsspeicher die Abfrage-Engine bekommt. Auf der Referenzanlage sind es 16 der 24 GB. Der Rest gehört den übrigen Diensten und dem Betriebssystem, das ohne Swap Luft braucht.
| Engine-Speicher | Speicher je Abfrage | Fertige Analysen bei 50 Nutzern |
|---|---|---|
| 8 GB | 1,92 GB | 73 |
| 16 GB | 3,84 GB | 124 |
Von 8 auf 16 GB stiegen die fertigen Analysen unter Höchstlast um 70 Prozent und der Durchsatz kurzer Abfragen um 43 Prozent. Wer auf einer Maschine mehr Leistung braucht, gibt zuerst der Engine mehr Speicher — nicht mehr Knoten.
Hochrechnung auf größere Umgebungen
Für die Planung braucht man Anhaltspunkte auch jenseits der vermessenen Maschine. Die folgende Tabelle rechnet die Messung hoch und skaliert dabei Kerne und Arbeitsspeicher gemeinsam — der Speicher muss mitwachsen, weil er es war, der die Parallelität schwerer Analysen hob: von 8 auf 16 GB stiegen die fertigen Analysen um 70 Prozent. Die Kerne setzen die Obergrenze. Die Kerne müssen nicht in einer Maschine stecken: mehrere Maschinen mit zusammen so vielen Kernen sind der Weg, den die Messung nahelegt.
| Kerne insgesamt | Arbeitsspeicher | davon Engine | Gleichzeitige Analysten | Kurze Abfragen je Sekunde | Zeilen |
|---|---|---|---|---|---|
| 6 (gemessen) | 24 GB | 16 GB | ≈ 50 | ≈ 55 | 60 Mio. |
| 12 | 48 GB | 32 GB | ≈ 100 | ≈ 105 | ≈ 120 Mio. |
| 24 | 96 GB | 64 GB | ≈ 200 | ≈ 210 | ≈ 240 Mio. |
| 48 | 192 GB | 128 GB | ≈ 400 | ≈ 425 | ≈ 480 Mio. |
Nur die erste Zeile ist gemessen. Alle weiteren sind hochgerechnet, Kerne und Speicher gemeinsam skaliert. Abfragemuster, Datenverteilung und Speicheranbindung wirken mit — messen Sie vor dem Produktivgang auf Ihrer eigenen Hardware.
Wann eine zweite Maschine hilft
Ein Worker auf einer zweiten Maschine bringt eigene Kerne und eigenen Arbeitsspeicher mit. Gemessen wurde das am 26. September 2026: zwei Cloud-Server mit je 6 vCPU, verbunden über einen WireGuard-Tunnel mit 12 bis 16 ms Laufzeit. Die Daten lagen auf der Hauptmaschine; der Worker las sie durch den Tunnel und hielt häufig gelesene Blöcke in 20 GB Zwischenspeicher.
| Gleichzeitige Nutzer | Abfragen je Minute mit / ohne Worker | Wartezeit Median mit / ohne | Wartezeit p90 mit / ohne |
|---|---|---|---|
| 4 | 22,5 / 17 | 12 s / 16 s | 19 s / 23 s |
| 10 | 22 / 18,5 | 33 s / 41 s | 41 s / 61 s |
| 20 | 23 / 13 | 71 s / 132 s | 94 s / 155 s |
Mit Worker hält die Anlage ihren Durchsatz auch bei 20 gleichzeitigen Nutzern: 77 Prozent mehr fertige Abfragen und die halbe Wartezeit. Ohne Worker stauen sich die Abfragen auf sechs Kernen.
Für einen einzelnen Nutzer ist der Gewinn kleiner: alle acht Abfragen nacheinander dauerten 34,0 statt 40,0 Sekunden. Große Scans und Joins profitieren am stärksten, einzelne Abfragen mit viel Datenaustausch über den Tunnel werden nicht schneller.
| TPC-H-Abfrage | Mit Worker | Ohne Worker |
|---|---|---|
| Q1 Preisübersicht | 1,4 s | 3,0 s |
| Q3 Versandpriorität | 2,5 s | 3,1 s |
| Q5 Umsatz je Land | 3,6 s | 4,5 s |
| Q6 Rabatt-Prognose | 0,8 s | 1,0 s |
| Q9 Gewinn je Produktgruppe | 7,9 s | 8,8 s |
| Q10 Retouren-Kunden | 4,5 s | 4,0 s |
| Q13 Kundenverteilung | 3,6 s | 6,1 s |
| Q18 Großaufträge | 9,8 s | 9,7 s |
TPC-H Skalierung 10: 60 Millionen Bestellpositionen, 15 Millionen Aufträge, 1,5 Millionen Kunden. Einzelwerte als Median aus zwei Durchläufen mit einem Nutzer; Dauerlast je zwei Minuten im Mix der acht Abfragen, direkt an die Abfrage-Engine und ohne Kachel-Cache, also der ungünstigste Fall. Beide Varianten liefen mit demselben Werkzeug direkt nacheinander.
Die Reihenfolge beim Ausbau
- Zuerst die eine Maschine ausreizen: der Engine mehr Arbeitsspeicher geben und, wo möglich, einen größeren Server mit mehr Kernen wählen. Das spart den Datenweg zwischen zwei Maschinen.
- Dann einen Worker auf einer eigenen Maschine dazunehmen, sobald etwa vier schwere Auswertungen gleichzeitig laufen oder die Hauptmaschine dauerhaft über 70 Prozent CPU liegt – typisch zu Monatsabschluss und Planungsrunden.
- Kaum Gewinn bringt ein Worker für einzelne kurze Abfragen, für Dashboards aus dem Kachel-Cache und für Abfragen auf Landezone, Speicher-Katalog oder föderierte Quellen, die auf der Hauptmaschine bleiben.
- Nie mehrere Knoten auf dieselbe Maschine stellen: sie teilen sich dieselben Kerne und lagen im Vergleich in fast jedem Szenario hinter der einfachen Konfiguration.
Kurzer Datenweg
Der Worker holt jeden Datenblock über das Netz. Ein privates Netz zwischen den Servern statt eines Tunnels durchs Internet verkürzt diesen Weg; ebenso eine Kopie des Objektspeichers auf der Worker-Maschine.
Seit v0.195.0 zeigt die Konsole unter Administration → Betrieb → Systemzustand → Rechenknoten jeden verbundenen Knoten mit Rolle, Adresse, vCPU, Arbeitsspeicher, CPU-Last, laufenden Aufgaben und Laufzeit. Ein Worker auf einer anderen Maschine ist eigens markiert. Fehlt ein Knoten länger als fünf Minuten, meldet sich der Alarm „Rechenknoten fehlt“.
Beispiel: ein mittelständisches Unternehmen
Zur Einordnung der Messung ein typisches Profil. Die Werte sind Annahmen, keine Messung.
| Annahme | Wert |
|---|---|
| Unternehmen | 250 Mitarbeitende, 30 bis 50 Auswertungsnutzer |
| Datenmenge | fünf Jahre ERP-Auftragspositionen, etwa 50 bis 60 Mio. Zeilen – ungefähr TPC-H Skalierung 10 |
| Spitzenlast | 5 bis 10 gleichzeitige Abfragen, etwa zum Monatsabschluss am Morgen |
| Server | typisch 16 bis 32 Kerne und 64 bis 128 GB Arbeitsspeicher |
Dashboards und Kennzahlen sind leichter als TPC-H und kommen meist aus dem Kachel-Cache: Antworten in Sekunden, auch auf einer Maschine. Für schwere Analysen zeigt die Messung bei zehn gleichzeitigen Nutzern 33 statt 41 Sekunden mit Worker. Auf einem üblichen Firmenserver mit deutlich mehr Kernen als die sechs der Testmaschine ist der erste Schritt deshalb der größere Server, der Worker der zweite.
Wenn zu knapp bemessen wurde
Zu knappe Speichergrenzen führen nicht zu falschen Ergebnissen, sondern zu Abbrüchen mit klarer Meldung. Beim Import von 60 Millionen Zeilen mit einem zu kleinen Engine-Limit beendete der Wächter den Container und startete ihn neu, jedes Mal binnen etwa 30 Sekunden. Mit dem für die Datenmenge angemessenen Limit lief derselbe Import ohne Zwischenfall durch.
Überlast ohne Worker
Im Lasttest vom 26. September 2026 ist die Abfrage-Engine ohne Worker bei 20 gleichzeitigen schweren Abfragen auf 6 vCPU abgestürzt: Der Java-Speicher des Koordinators lief voll, rund 30 Sekunden lang waren keine Abfragen möglich, bis Docker ihn neu gestartet hatte. Mit Worker lief dieselbe Last ohne Absturz. Richtig wäre, Last einzureihen oder einzelne Abfragen mit klarer Meldung abzubrechen; die Nachbesserung ist in Arbeit. Bis dahin: auf einer einzelnen 6-vCPU-Maschine die Leistungsklassen so setzen, dass nicht 20 schwere Abfragen gleichzeitig laufen.
Prüffrage bei einem Abbruch
Verschwindet der Fehler, wenn eine Zahl in der Konfiguration steigt? Dann war es Dimensionierung. Bleibt er, ist es etwas anderes — und dann lohnt der Blick in die Überwachung statt in die Speichereinstellungen.
Was hier nicht gemessen wurde
Die Zahlen gelten für eine Datenmenge von rund 60 Millionen Zeilen und für Maschinen mit 6 vCPU. Der Verbund wurde mit genau zwei Maschinen über einen Internet-Tunnel gemessen, nicht in einem privaten Netz und nicht mit mehr als einem Worker. Für Terabyte-Bestände, größere Server und andere Abfragemuster gibt es keine Messung. Wer für eine solche Umgebung plant, sollte auf der eigenen Hardware messen statt diese Werte hochzurechnen.
Stand: Diese Seite beschreibt lavalake 0.195.0. Produkt und Dokumentation liegen in getrennten Repositories – im Zweifel gilt, was die Konsole zeigt.
Etwas fehlt?
Wenn diese Seiten Ihre Frage nicht beantworten, zeigen wir die Plattform in einer halben Stunde an Ihrem Fall.
Demo vereinbaren