Türkei (Türkisch)
Germany (German)
Worldwide (English)
Der InnoDB Buffer Pool cached Tabellen- und Indexdaten im RAM. MySQL dokumentiert, dass dedizierte DB-Server einen großen Teil des physischen RAM dafür nutzen können.
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
MySQL/MariaDB anhand RAM, InnoDB Buffer Pool, Connections, NVMe-IOPS/Latenz, Redo-Logs, Swap und Workload dimensionieren.
Der InnoDB Buffer Pool cached Tabellen- und Indexdaten im RAM. MySQL dokumentiert, dass dedizierte DB-Server einen großen Teil des physischen RAM dafür nutzen können.
MySQL 8.4 nennt typischerweise etwa 50-75% des System-RAM für den Buffer Pool; Dedicated-Server-Autosizing nutzt über 4 GB etwa 75%. Auf gemischten Web+DB-Nodes darf das nicht blind übernommen werden.
Auf einem reinen DB-VPS kann viel RAM an InnoDB gehen. Auf einem gemischten VPS mit Panel, PHP-FPM, Redis und MySQL kann derselbe Prozentsatz OOM oder Swap verursachen.
Zuerst Workload klassifizieren: OLTP-Random-Queries, Analytics-Scans, WordPress/WooCommerce-Metadaten und API-Transaktionen verhalten sich unterschiedlich.
Ziel ist, den aktiven Working Set im RAM zu halten. Zu klein verursacht Disk Reads, zu groß nimmt OS und Connection-/Query-Memory den Platz. 50-75% sind nur ein Startpunkt.
MariaDB nutzt ebenfalls den InnoDB Buffer Pool. Wegen Versions-/Default-Unterschieden MySQL-Werte nicht blind kopieren, sondern MariaDB-Doku und Metriken nutzen.
mysql -e "SELECT @@version, @@innodb_buffer_pool_size;"mysql -e "SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool%';"mysql -e "SHOW ENGINE INNODB STATUS\G"MySQL-RAM besteht nicht nur aus Buffer Pool. Connections können Sort-/Join-/Read-Buffer allokieren; Temp Tables, Thread Cache und Performance Schema brauchen ebenfalls RAM. max_connections=1000 erzeugt keine Kapazität.
Bei Connection Pools echte gleichzeitige und idle Connections messen. OOM kann bei Peaks auftreten, obwohl RAM normalerweise frei aussieht.
Buffer-Pool-Misses, Redo-Log-Flush, fsync, Temp-Table-Spill und Checkpoints sind latenzsensitiv. 4K-Random-Latenz und p95/p99 sind oft wichtiger als hoher sequentieller Durchsatz.
NVMe beschreibt eventuell das Medium, aber nicht Backend oder IOPS-Limits. Die konkrete VM mit fio und DB-Workload testen.
Swap ist nicht grundsätzlich falsch, aber permanentes Auslagern des aktiven DB-Working-Sets erhöht Latenz stark. Dauerhafte Swap-I/O signalisiert Memory Pressure.
free -hvmstat 1 20iostat -x 1 20mysqladmin processlistOLTP mit hoher Parallelität profitiert von mehr Kernen; wenige schwere Queries eher von Pro-Core-Leistung. Schlechte Queries werden durch mehr CPU nicht automatisch gut.
Kleine WordPress-DB: 2-4 vCPU, 4-8 GB RAM, latenzarme NVMe. Mittlere WooCommerce/API-DB: 4-8 vCPU, 8-32 GB. Intensive DB: 8-16+ starke Kerne, 32-128+ GB ECC, Enterprise-NVMe-Mirror und separates Backup.
| Workload | CPU | RAM | Storage |
|---|---|---|---|
| WordPress/WooCommerce | Gute Pro-Core-Leistung | Working Set + Cache | Niedrige Random-Latenz |
| Intensives OLTP | Mehr Kerne | Großer Buffer Pool | Hohe IOPS |
| Reporting | Parallele CPU | Viel RAM | Sequential + Random Mix |
Mindestanforderungen nicht mit Produktionskapazität verwechseln. Peak-Workload, Backup, Wachstumsreserve, Ressourcenpolitik und Recovery-Plan gemeinsam bewerten.
Auf dediziertem DB-Server oft etwa 50-75% als Start; auf gemischtem Host zuerst RAM für andere Dienste reservieren.
Nein, aber niedrige Latenz und hohe IOPS sind bei hoher Last sehr vorteilhaft.
CPU, RAM, Storage, Netzwerk und Betrieb gemeinsam bewerten; ein größeres Paket ohne Engpassanalyse ist selten eine dauerhafte Lösung.