Ramdrive - Für den Servereinsatz sinnvoll?

S

seraphim

New Member
Ich habe mir einiges über Ramdrives angeschaut und frage mich nun ob der Produktiveinsatz auf einem Server sinnvoll bzw. möglich wäre und was es für Möglichkeiten damit gibt.

Mein Gedankengang war folgender:
-Erstellen eines Ramdrive direkt nach dem Boot
-Spiegeln der Systempartition auf das Ramdrive
-Systempfade auf das Ramdrive umstellen und die enorme Geschwindigkeit des Ramdrives nutzen
-z.B. mittels rsync regelmäßig das Ramdrive auf die Systempartition spiegeln

Das gleiche vllt auch für die httproots oder sogar nur für die httproots...

Was haltet ihr von Ramdrives im Serverbereich? Sinnvoll? Gibt es Vor- oder Nachteile die ich übersehen habe? Gibt es vielleicht sogar schon "komplettlösungen" um das OS auf einem Ramdrive laufen zu lassen? Kann man die Spiegelung vllt sogar über einen Raid Modus laufen lassen?
 
Last edited by a moderator:
Ist doch aus mehreren Gründen Quatsch:
- Wenn das System mal geladen wurde, ist die Menge an Zugriffen auf die Systempartition nicht so hoch, dass man davon übermäßig profitieren würde.

- RAM Drives (was auch immer Du darunter genau verstehst) sind für akzeptable Größen viel zu teuer.

- Die Inhalte sind weg, wenn der Strom weg ist, das ist für einen Server Harakiri!!! :eek:

Wenn Du unglaublich viel Speed brauchst, dann besorg Dir ein RevoDrive. Da wird SATA als Bottleneck umgangen und der PCIe direkt abgegriffen. Da hat man dann schon mal 1Gbyte/s lesen und schreiben. Und ich meine nicht ein Gbit, sonder wirklich ein Gbyte!! :D Mehr kann man kaum sinnvoll brauchen.
 
Nunja gegen das Strom-Weg-Daten-Weg Problem eben das periodische Spiegeln des Ramdrive auf die Platte.

Bei Zugriffsintensiven Websites könnte man doch das HTTPRoot in nen Ramdrive legen und den Ordner für Uploads und dergleichen auf der HDD belassen eig. oder? Das wäre ja bei seeeeehr vielen Foren/CMS doch eig. schon eine enorme Beschleunigung, eig. für gesamt Apache (ohne jetzt dabei im Hinterkopf zu haben ob und was Apache selber schon optimiert). Und die HTTPRoots kann man idR in nen Ramdrive von sogar nur 12MB legen, mehr machen viele php Scripte und html Seiten sowieso nie aus.

Es geht ja nicht nur um den Datendurchsatz sondern auch um die Geschwindigkeit mit der das ganze angesteuert wird, und da ist es günstiger vllt. 500 MB Ram abzuknapsen als eine teure SSD zu beschaffen die je nach Technologie sogar Verschleißerscheinungen aufzeigen kann.
 
Ein Server sollte auf Zuverlässigkeit ausgelegt sein. Ein Ram Drive ist das Gegenteil von zuverlässig.

"Syncs" auf die Platte können gar nicht so oft passieren, dass nicht bei Stromausfall ein inkonsistenter Zustand entsteht.

Du kannst den Server auch gelb anstreichen, wenn Dir das besser gefällt, Du kannst auch ein selbstmörderisches RAM Drive machen oder ihn nach einer Wasserader ausrichten. Ist ja nicht mein Server (Gott sei Dank).

Die Methoden, die bei Servern (sinnvollerweise) zur Beschleunigung verwendet werden, sind nunmal:
- genug Speicher (OHNE RAMdrive), denn Linux cached auch SELBST!!
- Raid10 und/oder neuerdings halt auch
- SSDs für besonders oft gebrauchte Dateien
 
Wenn ich genug Geld habe um mir sowas zu leisten dann kann ich auch nen Informatikstudenten als Haussklaven halten und den dazu zwingen das für mich einzurichten und alle 5 Minuten manuell nen Sync zu fahren *g*
 
Ich muss Thunderbyte etwas widersprechen. Auch bei Servern kann eine Ramdisk durchaus sinnvoll genutzt werden. Man denke dabei nur an diverse Anwendungscaches oder temporären Daten.
Wenn die verloren gehen, interessiert es keinen. Da kann man schon mal eine Ramdisk hernehmen.
 
Ich verstehe nicht, warum Änderungen verloren gehen sollten.. an was für Anwendungen denkt'n ihr?

Ich pack meine Website (ohne Datenbank oder andere Datenspeicherorte, die sich veränder können!) beim Serverstart von der Festplatte in den RAM. Stromausfall, Server wird wieder hoch gefahren, Daten werden wieder in den RAM gepackt. Was verlier ich denn da? :rolleyes:
 
Letztendlich fehlt dir dieser Speicher für das Caching durch den Linux-Kernel. Und der macht seine Aufgabe eigentlich recht ordentlich, reagiert vor allem dynamischer, wenn sich die Anforderungen zwischenzeitlich mal ändern sollten.
 
Ein OCZ RevoDrive (bringt auch nahezu 1Gbyte/sec) mit 120GB liegt bei rund 300€: http://geizhals.at/deutschland/666986

Das ist jetzt nicht dramatisch viel für überragende Performance. Wobei die Zugriffszeit - und darauf kommt es doch wohl für hohe Websiteladegeschwindigkeiten an - auch bei einer stinknormalen SSD schon extrem schnell ist.

Viel dramatischer als die Zugriffszeiten auf Datenträger sind doch die "Verluste" an Geschwindigkeit ab der Netzwerkkarte bis zum Client. Insofern ist doch die Diskussion hier echt irrelevant.
 
Wenn du nicht gerade die Daten von der anderen Seite des Planeten holst oder ins letzte afrikanische Dorf schickst, kann man das wohl vernachlässigen.
Für "mich" als Serverbetreiber ist es doch eher interessant, wie lang meine Machine damit beschäftigt ist, die Website zusammen zu bauen. Und wenn das Generieren der Site schon paar Sekunden dauert, sind mir die paar Millisekunden Latenz bis zum Client erstrecht egal.

Also bevorzuge ich an der Stelle schon vernünftige Datenträger, die mir die Leistung bringen, die ich benötige. Setz ich hier auf den falschen Datenträger könnte das die Anzahl der gleichzeitigen Besucher massiv nach unten drücken.
Wenn man am Ende vor der Wahl steht 10 Webserver mit SATA/SAS Platten betreiben zu müssen oder vielleicht 2-3 mit Ramdisk, überlegt man sich das schon. ;)
 
Wenn Du schon soviel RAM übrig hast, kannst Du ihn auch für einen Reverse-Proxy nutzen.
Der hält dann imer die zuletzt aufgerufenen Webseiten vor, so daß sie der Webserver nicht immer neu rendern muß.
So macht es z.B. Wikipedia.

PS: Für Deinen ursprünglichen Ansatz bietet sich statt zyklischem rsync eher unionfs an.
Damit können dann alle statischen Dateien aus der RAM-Disk kommen, Konfigurationen aber trotzdem direkt auf Platte geschrieben werden.
Das ist z.B. bei Live-CDs üblich.
 
@Firewire: Genau das war auch mein Hintergedanke. Der Flaschenhals ist ja eh spätestens die 100MBit Anbindung ;-)

Das mit dem Verlegen vom HTTPRoot in nen RamDrive ist eig. gar keine so üble Idee... Damit könnte man Apache doch bestimmt Beine machen wenn es um aufwändigere Arbeiten mit PHP geht...
 
Damit könnte man Apache doch bestimmt Beine machen wenn es um aufwändigere Arbeiten mit PHP geht...
Click to expand...
Was hat Apache mit PHP zu tun? Ausser dass das eine eine Schnittstelle zum anderen hat :confused:

Definier _aufwendiges Arbeiten_. Ich versteh darunter Datenbankabfragen und mathematische Berechnungen (Konvertieren, ....), nicht den Zugriff auf viele Dateien.

Wie schon von anderen gesagt macht Linux Caching seine Arbeit sehr gut ohne dass man Dateien welche alle x Jahre mal abgerufen werden im teuren RAM vorhalten muss. Eine Applikation zur Zusammenarbeit mit memcached zu ueberreden und einen reverse-proxy zum caching von Inhalten zu verwenden hilft bedeutend mehr als www-root in ein tmpfs zu setzen.
 
Hmm stimmt... Apache/PHP etc sind nicht so ganz mein Metier, kenn da nur das was ich selber brauche... Hab eh das Gros meiner Seiten als HTML gefasst von daher wumps ^^

Für einige meiner Perlscripte werd ich mir aber definitiv nen Ramdrive anlegen, dann sind die ne ganze Ecke flotter durch mit diversen Filehandles ;-)
 
Last edited by a moderator:
Mach was Du meinst, dass Du machen musst. Ich glaube dass die Aktion kaum bis keine Verbesserung bringen wird und die Zeit viel besser darin investiert wäre, die Applikation zu optimieren (Datenbankzugriffe reduzieren), oder File- und Datenbank-Caches einrichten.

Ich glaube, dass Zeit weniger beim physischen Lesen der Dateien verloren geht, als vielmehr bei Datenbankzugriffen etc.

Aber mach was Du meinst machen zu müssen. :rolleyes:
 
seraphim said:
Für einige meiner Perlscripte werd ich mir aber definitiv nen Ramdrive anlegen, dann sind die ne ganze Ecke flotter durch mit diversen Filehandles ;-)
Click to expand...
Wenn gerade der Sync läuft wird es wieder ausgebremst weil Dateien ggf. gelockt sind bzw. die Lese-Kapazität vom Sync genutzt wird.

Mal in meine Experimentier-Phase zurück versetzt (Linux-Kernel 0.96x, 512 MB, 486er oder Pentium):
Ich habe das Selbe ebenfalls schon versucht. Damals war der Speicher deutlich geringer (und teurer) als heute und die Dateien ebenfalls kleiner. Aber eben auch die gesamte Performance, so dass man Ergebnisse noch mit der händischen Stoppuhr messen konnte. ;)
Ich habe damals festgestellt, dass es keinen Mehrwert bringt. Insbesondere schien es mir damals so, dass das Öffnen von Dateien genauso lang dauert. Egal ob RamFS oder HD. (Ich hatte es damals mit sehr vielen kleinen Dateien zu tun.)
Ich habe einige Versuche unternommen mit RamFS (ohne HD-Cache, denn mangels Speicher ging entweder das eine oder das andere) im Vergleich zur HD (ohne und mit Cache). (Damals hatten die Festplatten noch keinen eigenen Cache!)
HD ohne Cache war natürlich am langsamsten. RamDrive und HD+Cache waren etwa gleich auf. Das variierte darüber wie viel Dateien gleichzeitig offen waren. HD-Cache ging damals in die Knie wenn zu viele Files auf einmal geöffnet wurden.
Dazu kam der Vorteil, dass der Cache sich dem vorhandenen Ram anpasste. Ein RamDrive hat man eine feste Größe zugeordnet und das fehlte ggf. dem Linux-System an Speicher was dann den Swap aktivierte.

Wenn ich mir allerdings die heutigen Entwicklungen ansehe:
- Der HD-Cache von Linux ist sehr "intelligent" und auch effizienter geworden.
- Festplatten kommen mit einem eigenen Cache daher.
- Performante File-Systeme.
- etc.

Dann würde ich darauf tippen, dass heute auch ein RamDrive keine echte Performance mehr bringt. Ausgenommen als TmpFS.

huschi.
 
Für GameServer würde ich es mal einfach testen. Wenn genügend Ram da ist, kann man das die Dateien auf tempfs kopieren und dann on the fly mounten, wenn er fertig ist.

Geht natürlich nur, wenn man Symlinks nutzt.
 
Selbst wenn es heir um Gameserver ginge; welchen Vorteil soll das bringen :confused:
Die Dateien werden zu Beginn geladen, zur Laufzeit ist kaum Festplattenzugriff zu verzeichnen (ausser sqlite-Datenbanken von verschiedenen Mods und Logfile-Schreiben wobei beides aber eh afaik durch einen separaten Thread erfolgt und somit nicht den GS stoergt)
 
You must log in or register to reply here.
Back
Top