Entscheidung: Serverdimensionierung

Korrekte Dimensionierung beginnt beim Workload-Profil (OLTP, Data Warehouse, gemischt) und erfordert, den echten Engpass zu finden (CPU, I/O oder RAM). Goldene Regel: Der häufig genutzte Datenbestand (Working Set) muss in den RAM passen; erst messen, dann skalieren, und Reserve für Lastspitzen lassen. Dieser Baum hilft dir, die Workload zu bestimmen und je nach Engpass Ressource und Skalierungsrichtung (vertikal/horizontal) zu wählen.

Wie sieht dein Workload-Profil aus?

Die Dimensionierung beginnt bei der Workload, denn OLTP- und Analyselasten erfordern völlig unterschiedliche Ressourcenprofile. Was ist die überwiegende Arbeit des Systems: viele kleine, schnelle Transaktionen (OLTP), Reporting/Analysen mit großen Scans und Aggregationen (DWH) oder eine Mischung aus beidem? Bist du nicht sicher, musst du zuerst messen.

• OLTP — viele kleine, kurze Transaktionen (Web/Anwendung)
• Analyse / Data Warehouse (DWH) — große Scans und Aggregationen
• Gemischte Workload, oder ich bin nicht sicher
• Ich kenne den Engpass; soll ich vertikal oder horizontal skalieren?

Wo liegt der Engpass: RAM, I/O oder CPU?

Finde bei OLTP den echten Engpass, statt blind Ressourcen hinzuzufügen. Sieh dir deine Metriken an: Passen häufig genutzte Daten nicht in den RAM und gibt es viele Disk-Lesevorgänge (RAM/I/O), reichen Disk-Latenz/IOPS nicht aus (I/O), oder liegen die Daten bereits im Speicher, aber die CPU ist ausgelastet (CPU)? Die falsche Ressource zu skalieren verschwendet Geld und Zeit.

• Häufig genutzte Daten passen nicht in den RAM; viele Disk-Lesevorgänge
• Daten liegen im Speicher, aber Disk-Latenz/IOPS reichen nicht (schreibintensiv)
• Daten liegen im Speicher und die Disk ist in Ordnung, aber die CPU ist ständig ausgelastet

Empfehlung: erst messen, dann dimensionieren

Hardware nach Schätzungen zu kaufen, führt fast immer zur falschen Größe. Workload-Profil und Engpass ergeben sich aus echten Metriken. Dimensionierung ist keine Schätzung, sondern eine messungsgetriebene Iteration.

Empfehlung: RAM ergänzen — das Working Set muss in den Speicher passen

Die wichtigste OLTP-Regel: Häufig genutzte Daten und Indizes (das Working Set) müssen in den Speicher (Buffer/Cache) passen. Tun sie das nicht, geht jede Abfrage auf die Disk, die Latenz explodiert und I/O wird zum Engpass. RAM ist meist die Investition mit der höchsten Rendite.

Empfehlung: I/O-Schicht stärken (IOPS/Latenz)

Selbst wenn die Daten im Speicher liegen, ist unter schreibintensiver Last (Commit, WAL/Redo/binlog, Checkpoint) die Disk-Geschwindigkeit entscheidend. Das Problem ist hier nicht die Kapazität, sondern IOPS und Latenz. Die falsche Disk-Klasse zwingt das System trotz schneller CPU/RAM in die Knie.

Empfehlung: CPU-Engpass beheben (zuerst Abfragen, dann Kerne)

Ist die CPU ausgelastet, während die Daten im Speicher liegen und die Disk in Ordnung ist, liegt die Ursache meist in ineffizienten Abfragen (schlechte Pläne, fehlende Indizes, viele kleine Abfragen) oder übermäßiger Parallelität. Die Last zu senken, bevor man Kerne hinzufügt, ist meist günstiger und wirksamer.

Empfehlung: Analyse/DWH — Durchsatz, Parallelität und horizontale Skalierung

Eine Data-Warehouse-Workload besteht aus wenigen schweren Abfragen, die große Tabellen scannen und aggregieren. Priorität hat hier nicht niedrige Latenz, sondern hoher Scan-Durchsatz, Parallelität und meist eine horizontal skalierbare Architektur.

Allgemeines Prinzip: vertikal vs. horizontal + Reserve + erst messen

Wie du skalierst, zählt ebenso wie welche Ressource du skalierst. Vertikal (größere Maschine) ist einfach, hat aber eine Obergrenze und einen Single Point of Failure; horizontal (mehr Maschinen) skaliert, bringt aber Komplexität. Lass in jedem Fall Reserve für Lastspitzen und validiere die Entscheidung mit Messungen.