MySQL 5.7 oder 8 absolute Minimum RAM-Konfiguration?

[Edward11]

Diese Frage kommt ziemlich oft, und die Antwort darauf ist dieselbe und das ist verständlich.

Hängt von der Arbeitsbelastung ab.

Aber lassen Sie uns sagen, Leistung ist nicht das Ziel. Das Ziel ist es, Mysql so wenig RAM wie möglich zu nehmen.

Zu verstehen, wie MySQL funktioniert, ist nicht so einfach und erfordert viel Erfahrung.

Ich hätte gerne eine MySQL-Konfiguration, die nicht im RAM "expandiert".

Zum Beispiel kann das minimale Setup von Nginx + PHP-FPM + Laravel innerhalb von 20 MB RAM für jede Anforderung ausgeführt werden. Wenn wir dieses Setup plötzlich um mysql erweitern, brauche ich zusätzliche ~ 100MB.

Ist es möglich, mysql anzuweisen, für jede Abfrage immer Festplatten-E / A zu verwenden, und auf diese Weise den RAM zu schonen?

[__blackjack__]

@Edward11: Was soll das bringen? RAM ist nicht dazu da geschont zu werden, sondern um benutzt zu werden.

[DasIch]

https://dev.mysql.com/doc/refman/8.0/en/memory-use.html verrät alles was du wissen musst. Du solltest natürlich nicht den Empfehlungen folgen. 100MB dürfte allerdings schon sehr nah an der unteren Grenze sein.

[noisefloor]

Hallo,

bei Datenbanken gilt ja immer noch: viel (RAM) hilft viel.

Wenn du aus welchen Gründen auch immer RAM sparen musst -> nimm' eine DB die per se weniger RAM benutzt.

Gruß, noisefloor

[DasIch]

MySQL (und Postgres) sind schon dafür gedacht wenig RAM zu benutzen oder zumindest dafür dass der Großteil der Daten auf der Festplatte liegt. Ich denke nicht dass man beim wechseln sich da viel ersparen kann. Im Gegenteil alles was neuer ist, wird tendenziell eher dafür gedacht sein auf Systemen zu laufen wo man (fast) die ganze Datenbank im RAM halten kann.

[naheliegend]

Hängt vielleicht teilweise mit der Frage zusammen: Ich lese immer wieder, dass man versucht eine ganze DB im RAM zu halten. Aber warum?
Kann das DBMS nicht intelligent entscheiden, welche Daten oder Indexe in den Cache müssen, weil nur die bestimmt abgefragt werden?

[sparrow]

Wenn die Datenbank komplett im RAM ist, braucht keine Instanz irgend etwas zu entscheiden. Schneller als dort kann der Zugriff auf eine große Menge an Daten nicht sein.

[noisefloor]

Hallo,

Kann das DBMS nicht intelligent entscheiden, welche Daten oder Indexe in den Cache müssen, weil nur die bestimmt abgefragt werden?

Das hat ja auch nur bedingt was mit "intelligent", sondern eher mit Wahrscheinlichkeiten und Spekulation. Grundsätzlich muss man ja davon ausgehen, dass alle Daten aus der Datenbank angefragt werden könnten. Sonst bräuchte man die nicht in der DB

Gruß, noisefloor

[DasIch]

Kann das DBMS nicht intelligent entscheiden, welche Daten oder Indexe in den Cache müssen, weil nur die bestimmt abgefragt werden?

Jein. Ein DBMS kann schon versuchen intelligent zu entscheiden wann, welche Daten gelesen und geschrieben werden und was im RAM gehalten wird. Das ist allerdings ein sehr komplexes Thema und nicht alle Datenbanken sind da sonderlich gut drin. Das Betriebssystem macht sowas von sich aus auch schon und einige Datenbanken verlassen sich einfach darauf, obwohl die Datenbank dies in der Theorie besser könnte als das Betriebssystem. (Wenn man nach databases und mmap sucht findet man einige Diskussionen zu dem Thema). Diese Entscheidungen zu fällen kostet natürlich auch Zeit.

Außerdem ist es immer möglich dass einzelne Queries oder mehrere parallel laufende Queries zusammen die Verarbeitung von mehr Daten erfordern als in den RAM passt. Ab dem Punkt zahlst du dann den Preis dafür dass du auf Storage zugreifen musst der langsamer als RAM ist.

Darüberhinaus kommt aber noch ein anderes Problem hinzu: Allein die Möglichkeit dass Daten nicht im RAM liegen könnten, zwingt dich zur Indirektion da du keinen gewöhnlichen Pointer auf Daten die nicht im RAM liegen haben kannst. Diese Indirektion wirkt sich erheblich auf die Performance aus. Deswegen hast du dann, wie schon angesprochen, moderne Datenbanken wie SAP HANA die einfach alles im RAM halten und Bedarf für immer größere EC2 Instanzen schaffen.

[naheliegend]

Und deswegen entscheidet man sich einfach die komplette DB in dem RAM zu drücken? Wie ist das denn bei DB die mehrere TB groß sind?

Muss man die DB aktiv in den RAM schieben oder passiert das vom DBMS automatisch?

[__deets__]

Es heißt ja nirgends muss. Nur wenn möglich. Natürlich kannst du immer mehr Daten haben als RAM. Du kannst auch immer mehr Daten haben was eine Platte. Und dann? Heißt es dann alle Hoffnung fahren lassen?

Wie DasIch ja schon sagte gibt’s DBs die das grundsätzlich machen. Andere wird man konfigurieren können.

[DasIch]

Und deswegen entscheidet man sich einfach die komplette DB in dem RAM zu drücken? Wie ist das denn bei DB die mehrere TB groß sind?

Wenn es für die Anwendung sinnvoll ist.

EC2 High Memory instances offer 3, 6, 9, 12, 18, and 24 TiB of memory in an instance.

Also ein paar TB sind noch kein Problem.

Muss man die DB aktiv in den RAM schieben oder passiert das vom DBMS automatisch?

Das passiert automatisch wie bei Redis oder Memcached auch. Die Festplatte nutzt man, wenn überhaupt, für WAL und Backups, damit man bei einem Neustart keine Daten verliert.

Das ist natürlich nur etwas was man macht wenn man größtmögliche Performance braucht und man dies auch bezahlen kann, wirklich bezahlbar ist sowas auch erst in den letzten ~10 Jahren geworden. Gerade für analytische Anwendungen gibt es auch Systeme die deutlich langsamer und günstiger sind wie Apache Hive oder Delta Lake um auf Daten zuzugreifen die noch im S3 Bucket liegen und die du lokal überhaupt gar nicht hast.

[naheliegend]

Danke.