Linux Speicherverwaltung mit 2.6

[Hucke]

Mich würde mal interessieren wie Linux mit dem 2.6.x Kernel den Speicher verteilt. Irgendwo hab ich gelesen, dass Linux mit 8 GB RAM klar kommt. Jetzt stellt sich mir die Frage wieviel RAM die Prozesse dann maximal so verballern dürfen. Praktisch betrachtet gehts mir da um eine MySQL Datenbank. Je mehr Speicher so ein Ding hat, desto besser. Allerdings sind 2GB ja normalerweise die Grenze.
Weiß wer ob da mehr geht? Oder schränkt da einfach die Architektur ein und mit 64 Bit gehts erst weiter.

[Coda]

Man kann unter 32-Bit-Linux 3,5GiB virtuellen Adressraum für Programme reservieren und über PAE wohl auch die 8GiB auf mehrere dieser Prozesse verteilen.

Ich würde aber dringend vorschlagen 64-Bit zu verwenden, falls mehr als 4GiB Speicher vorhanden sind.

[Endorphine]

PAE hat keinen Sinn bei der Verwendung von Open-Source Betriebssystemen und Applikationen. In dem Fall sollte man gar keine Zeit mit PAE verschwenden, sondern die amd64-Version des Betriebssystems verwenden und MySQL selbst bauen.

Ich kann keinen Sinn darin erkennen, sich bei einem reinen open-source System mit 32-Bit Beschränkungen herumzuschlagen.

[gentoo]

Bei mysql ist nicht der Speicher das Problem, sondern
dass MySql sehr schlecht auf komplexe Abfragen unter Last skaliert.

Ich würde dir bei grossen Datenbanken zu oracle oder postgres raten.
Beide dbs bieten gute Optionen für performancetuning, zusätzlich
eine transacioncontroll und untestützung für stored procedures.


mfg,
gentoo

[Hucke]

Bei mysql ist nicht der Speicher das Problem, sondern
dass MySql sehr schlecht auf komplexe Abfragen unter Last skaliert.

Ich würde dir bei grossen Datenbanken zu oracle oder postgres raten.
Beide dbs bieten gute Optionen für performancetuning, zusätzlich
eine transacioncontroll und untestützung für stored procedures.


mfg,
gentoo

Tja, zunächst haben wir nur ein 32 Bit System auf das die Datenbank kann und dann ist der Chef noch geizig und möchte keine richtige Datenbank käuflich erwerben. Und mal ganz davon abgesehen, dass ein Großteil unserer Software in PHP gefrickelt wurde und zeit- und konstenaufwändig erstmal für ne neue Datenbank umgestrickt werden müsste.

Im Prinzip ne gute Idee, aber so nicht durchführbar. :D

Komplexe Abfragen, jo, Joins über mehrere Tabellen mag MySQL nicht. Können wir mit Leben. Transaktionen brauchen wir nicht wirklich, Stored Procedures werden auch von MySQL unterstützt. Eigentlich kann MySQL fast alles was eine Datenbank so braucht. Nur Online Backup ist ein kostenpflichtiges Extrapaket.

Alles in allem steht wohl in den nächsten Jahren mal der Umzug auf ne richtige Datenbank an. Bin mal gespannt.

[The_Invisible]

nanana, macht mysql doch nicht schlechter als es wirklich ist

wir haben einen dns server auf mysql basis laufen mit ca 60.000 rr einträge und 20 anfragen pro sekunde. und jetzt kommts: die kiste ist ein celi 500 mit 64mb ram (kein witz) und läuft mit 80% idle time.

versucht das doch mal mit einer oracle datenbank ;)

mfg

[gentoo]

nanana, macht mysql doch nicht schlechter als es wirklich ist

wir haben einen dns server auf mysql basis laufen mit ca 60.000 rr einträge und 20 anfragen pro sekunde. und jetzt kommts: die kiste ist ein celi 500 mit 64mb ram (kein witz) und läuft mit 80% idle time.

versucht das doch mal mit einer oracle datenbank


Ich würde nie auf die Idee kommen MySQL schlecht zu machen.;)
MySQL ist verdammt gut und schnell bei kleineren und einfachen
Datenbanken ( Da kann weder postgres noch oracle von
der Performance mithalten).

Nur dachte ich mir dass die Datenbank grösser wäre, da er
8 GB Speicher verbauen wollte und hier einfach komplexere Datenbanken
einen Vorteil gegenüber MySQL haben.

lg,
gentoo