Hallo,
was macht man, wenn das RAID der Falschenhals eines Systems ist?
Der Server hat einen 3ware Hardwareraid Controller mit 4 SATA Festplatten als RAID 10. Aufgrund des Platzmangels würde ich gerne erstmal nicht mehr Festplatten einbauen.
Mehrere Prozesse (HTTP-Requests mit Datenbankzugriffen) arbeiten parallel und Festplattenseeks lassen sich nicht vermeiden, da die Datenbank größer als der RAM ist. Anfragen aus dem Cache sind schnell genug, sobald aber auf Daten zugegriffen wird, die nicht im RAM sind, werden die Zugriffe verständlicherweise langsam.
Wenn man nach Performance Benchmarks im Web oder Linux-Magazin nachliest, sind das meist für mich meist unbrauchbar, da die CPU im Vordergrund steht, oder die Filesystembenchmarks oft mit nur einem lesenden/schreibenden Prozess arbeiten.
Bringen Festplatten mit NCQ (native command queuing) merkbaren Performancegewinn?
Naja, vielleicht kennt jemand das Problem und hat ein paar Tipps...
Gruß, Thomas
Hallo Thomas,
On 4/18/07, Thomas Guettler guettli@thomas-guettler.de wrote:
was macht man, wenn das RAID der Falschenhals eines Systems ist?
externe Controller mit viel Cache würde ich empfehlen. Du bist dir aber sicher, das Problem richtig identifiziert zu haben? Bei Datenbanken kann es alle möglichen Probleme geben, falsche oder fehlende Indizes sind da nur die offensichtlichsten.
Viele Grüße, Torsten
Am 18.04.2007 um 22:12 schrieb Thomas Guettler:
was macht man, wenn das RAID der Falschenhals eines Systems ist?
<SNIP>
Bist Du sicher, daß das das Problem ist?
Ansonsten nur der übliche Weg: Geld draufschmeißen. Meint, Web- und DB-Server auf zwei Maschinen verteilen, beide mit schön Hauptspeicher ausrüsten. Auf dem Web-Server nen Apache mit mod_cache/mod_proxy davorinstallieren, sofern nicht bereits ein Apache läuft. Evtl. kannst Du ja mal mit mod_cache/mod_proxy spielen und schaun, ob es was bringt.
MfG Sebastian
On Thu, Apr 19, 2007 at 10:51:39AM +0200, Sebastian Hegler wrote:
Am 18.04.2007 um 22:12 schrieb Thomas Guettler:
was macht man, wenn das RAID der Falschenhals eines Systems ist?
<SNIP>
Bist Du sicher, daß das das Problem ist?
Ich denke schon: Load>4, CPU 50% idle, wa (IO wait) groß
Fehlende Datenbank Indizes sind es vermutlich auch nicht. Die gleiche Anfrage braucht beim zweiten Aufruf einiges weniger Zeit. Mit dem Kommando "time" auf der Shell sieht man: sys und user sind beim ersten und beim zweiten Aufruf gleich. Der Wert von real ist beim zweiten Mal einiges größer. Da die Testanfrage auf der Shell keine Netzwerkverbindungen benutzt, denke, ich dass der IO-Zugriff der Flaschenhals ist.
Ansonsten nur der übliche Weg: Geld draufschmeißen. Meint, Web- und DB-Server auf zwei Maschinen verteilen, beide mit schön Hauptspeicher ausrüsten. Auf dem Web-Server nen Apache mit mod_cache/mod_proxy davorinstallieren, sofern nicht bereits ein Apache läuft. Evtl. kannst Du ja mal mit mod_cache/mod_proxy spielen und schaun, ob es was bringt.
Ich vermute, dass hier ein Rechner mit doppeltem RAM und schnelleren/mehr Platten sinnvoller ist. Da ich eher Softwareentwickler als Hardwareguru bin, wollte ich hier mal hören, was andere denken.
Sicherlich stößt ein Rechner irgendwann an die Grenzen, doch leider lässt sich bei der Anwendung nicht cachen. Es gibt vielleicht 20-30 kleine Icons, CSS und JS Dateien. Der Rest wird pro Request dynamisch erzeugt.
Leider lässt sich unter Linux das IO-Verhalten eines Prozesses nicht richtig nachvollziehen. Solaris und Windows sollen da besser sein. Wenn mehrere Prozesse auf dem Rechner laufen, nützen die Ausgaben von iostat nicht viel, weil sie die Daten nur pro Partition anzeigen.
Gruß, Thomas
On 4/19/07, Thomas Guettler guettli@thomas-guettler.de wrote:
Fehlende Datenbank Indizes sind es vermutlich auch nicht.
Das wäre aber wie schon gesagt der einfache Fall. Es könnte aber sein, dass völlig unnötige DB-Operationen durchgeführt werden, die u.U. gar nicht gebraucht werden. Von Ferne ist das schwer einzuschätzen. Wieviel parallele Anwender greifen überhaupt zu?
Viele Grüße, Torsten
guettli@thomas-guettler.de (Thomas Guettler) writes:
was macht man, wenn das RAID der Falschenhals eines Systems ist?
Der Server hat einen 3ware Hardwareraid Controller mit 4 SATA Festplatten als RAID 10. Aufgrund des Platzmangels wÃŒrde ich gerne erstmal nicht mehr Festplatten einbauen.
Von Datenbanken habe ich kaum Ahnung, aber mit RAID habe ich schon mal was zu tun gehabt. Insofern ist folgendes etwas einseitig.
Ich bevorzuge Linux' SoftRAID (md). Aus Performancesicht gibt es meiner Erfahrung nach keinen Grund für Hardware-RAID bzw. "professionelle Storage-Lösungen". (Man kann über Zuverlässigkeit/Verfügbarkeit debattieren, aber das dauert lange und führt zu nichts.)
Gerade bei RAID 0 und 1 (und Kombinationen davon) reicht ein RAID-Kontroller nur die Daten durch. Das kann ein Linux-Rechner auch selber.
Ich kenne mich mit IDE-RAID-Kontrollern nicht aus, insofern weiß ich nicht, was die alles bremsen können. Hinsichtlich Schreib-Performance gab es bei 3ware bessere und schlechtere, aber Lesen können sie wohl alle. (Da ich an seriellem bisher nur mit SAS zu tun hatte, würde ich vielleicht sogar testen, die vier Platten an einen SAS-Kontroller anzuschließen. Da weiß ich wenigstens, daß die Kontroller gehen; aber SATA habe ich da noch nie direkt angeschlossen.)
Übrigens verteilt md die Lesezugriffe nicht (oder unzureichend) auf die Mirrors. Fürs Lesen nutzt du also praktisch nur zwei Platten. Hättest du ein RAID 5, würde durchschnittlich von drei Platten gelesen. Solange man nichts sehr schreibintensives tut, gibt es meines Wissens keinen guten Grund für RAID10.
Bringen Festplatten mit NCQ (native command queuing) merkbaren Performancegewinn?
Naja, ich weiß nicht... SCSI- bzw. SAS-Platten wären wahrscheinlich nützlicher. Ich habe schon mal gehört, daß im Datenbank-Umfeld Platten mit geringer Latenz schick sind. Also 15000 U/min; und die gibt es nicht als SATA.
Wenn Latenz (Seeks) wichtig ist, könntest du da viel Geld draufwerfen. Andererseits wäre mehr RAM sicher preiswerter. Die Frage ist eben, ob die Abfragen eine gewisse Lokalität haben, so daß es häufigere benötigte Dinge gibt, die gecacht werden können. Wenn alles gleich häufig genutzt wird (also z.B. jede Abfrage einmal die ganze Platte liest) und das deutlich größer als bezahlbarer RAM ist, nützt RAM eben nichts.
Sven
Guten Morgen Liste
Am Freitag, 20. April 2007 04:40 schrieb Sven Rudolph:
Ich bevorzuge Linux' SoftRAID (md). Aus Performancesicht gibt es meiner Erfahrung nach keinen Grund für Hardware-RAID bzw. "professionelle Storage-Lösungen".
ACK.
Ich habe das "Vergnügen" mit einem 3ware Escalade und einem Promise Controller. Ersterer schreibt nur mit max 10 MB/s und für zweiteren benötigt man ein spezielles Kernelmodul ohne Sourcen.
Gerade bei RAID 0 und 1 (und Kombinationen davon) reicht ein RAID-Kontroller nur die Daten durch. Das kann ein Linux-Rechner auch selber.
Selbst mit RAID 5 sind aktuelle CPUs nicht ansatzweise ausgelastet.
Wenn Latenz (Seeks) wichtig ist, könntest du da viel Geld draufwerfen. Andererseits wäre mehr RAM sicher preiswerter. Die Frage ist eben, ob die Abfragen eine gewisse Lokalität haben, so daß es häufigere benötigte Dinge gibt, die gecacht werden können. Wenn alles gleich häufig genutzt wird (also z.B. jede Abfrage einmal die ganze Platte liest) und das deutlich größer als bezahlbarer RAM ist, nützt RAM eben nichts.
Wenn die Datenmengen nicht zu groß sind wäre evt eine Festplatte aus RAM-Bausteinen eine Option. Die Dinger sind größer als normaler RAM, aber kleiner als Festplatten. http://hardware.thgweb.de/2005/09/12/festplatte_ohne_mechanik_und_superschne... http://hardware.thgweb.de/2005/12/23/hyperos_hyperdrive_iii_attackiert_gigab... Beide Links aus http://de.wikipedia.org/wiki/Solid_State_Disk
Bei neueren Kerneln (und passenden userspace) gibt es "ionice" zur Priorisierung von IO. Auf der Mailingliste von Opensuse (opensuse@opensuse.org) gab es da mal eine Diskussion. Das wichtigste steht in dieser Mail: Message-Id: 20070412165234.a475a801.eshsf@mbj.nifty.com
Jens
lug-dd@mailman.schlittermann.de
-
guettli＠thomas-guettler.de -
Jens Weiße -
Sebastian Hegler -
Sven Rudolph -
Torsten Werner