Intern: Sonnenuntergang auf dem grünen Planeten

Nero24

Administrator
Teammitglied
Mitglied seit
01.07.2000
Beiträge
24.066
Renomée
10.445
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2021
Vergangenes Wochenende hatten wir relativ kurzfristig eine Downtime von Planet 3DNow! <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1174721825">angekündigt</A>, ohne - wie sonst bei uns üblich - ausführlich zu erläutern, was gemacht werden soll und gemacht worden ist. Das möchten wir heute nachholen.

Nachdem Euer neuer Community-Server - aka Das Boot - <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1136883544">seit Anfang 2006 online</a> ist und zuverlässig seinen Dienst verrichtete, hatten wir aufgrund der massiv gestiegenen Besucherzahlen bereits Mitte Februar 2007 <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1172067659">ankündigen</A> müssen, dass die Maschine ein umfangreiches Hard- und Software Upgrade bekommen würde. Neue Prozessoren, einen Satz neuer Festplatten und vor allem ein neues Betriebssystem: Sun Solaris 10. Die Euphorie war riesig. Ein professionelles Server-Betriebssystem für den grünen Planeten, dazu eine Hardware, die Bäume ausreißen konnte. Gleich am ersten Tag ließ der Server seine Muskeln spielen. Ein neuer Besucher-Rekord, sowohl auf der Webseite, als auch im Forum und das mit einer Geschwindigkeit, die einen eher an statische HTML-Files im LAN, denn an dynamisch generierte PHP-Files auf einem Webserver schließen ließ, deuteten auf eine rosige Zukunft hin. Doch es sollte anders kommen...

Bereits 4 Tage nach der Inbetriebnahme des aufgerüsteten Servers <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1173100593">ereilte</A> uns aus heiterem Himmel und ohne Vorwarnung der Super-Gau für jeden Administrator: ein Totalabsturz des Systems und eine trotz Raid-1 regelrecht zerstückelte System-Partition. Der Schuldige war schnell ausgemacht. Ein fehlerhaft arbeitender SATA-Controller schien die System-Partition vernichtet zu haben. Zwar blieben von Anfang an Fragen offen - schließlich hatte uns dieser Controller bereits ein Jahr lang zuverlässig als Backup-Controller gedient - aber zunächst schien sich die alte Admin-Weisheit zu bewahrheiten, dass SCSI für einen stark frequentierten Webserver die einzig richtig Lösung ist. Allerdings hatten wir auch den Sil3114-Treiber unter Solaris (Status "known to work") auf der Rechnung. Aus verständlichen Gründen hatten wir allerdings nicht die Muse herauszufinden, ob nun der Controller oder der Treiber an der Misere schuld war. Gott Lob war den Daten - also den Inhalten der Webseite - nichts passiert. Die lagen auf einem SCSI-Raid. Nach fast 4 Tagen Downtime konnten wir den Server - nun in einer SCSI-only Konfiguration - wieder online bringen und glaubten uns über den Berg.

Allerdings hatten wir hier die Rechnung ohne den Wirt gemacht. Im Abstand von ein bis drei Tagen verabschiedete sich der Server mit einer kernel panic - vergleichbar einem Bluescreen unter Windows. Ein erster Blick in das dumpfile brachte zum Vorschein, dass der Absturz irgendetwas mit dem Netzwerk oder dem Netzwerk-Controller zu tun haben musste. Nur was? Nach dem fehlerhaften SATA-Treiber nun etwa auch noch ein fehlerhafter Broadcom-Treiber? Langsam machte sich Ernüchterung breit. Nach einem Jahr beinahe sorgenfreien Betriebs des Boot 1.0 nun Hiobsbotschaften im Tagesrhythmus. Haben wir beim Hardware-Upgrade irgendetwas falsch gemacht? Unsere Standard-Stabilitätstests unter Knoppix sagten "Nein". Alles ok. Hatten die neuen Hardware-Komponenten einen Patscher? Oder war es etwa ein Fehler auf Solaris 10 zu setzen? Noch tappten wir im Dunkeln.

Nach ein paar weiteren Abstürzen und etlichen Stunden Fehlersuche offenbarte sich ein erster Strohhalm an den wir uns klammern konnten. Die Bugbeschreibung <i>"On Solaris 10 Kernel Memory Corruption May be Seen in TCP/IP Under High Stress Resulting in a System Panic"</i> schien wie die Faust auf's Auge zu unserem Problem zu passen. Ein bisher nicht eingespielter Patch sollte alle Probleme lösen. Leider ein Trugschluss. Der Server zickte nach wie vor im 2-Tages Rhythmus herum und das ausgerechnet zur CeBIT. CeBIT? Genau! Sun ist doch auch auf der CeBIT, also schickten wir unsere "schnelle Eingreiftruppe" in Hannover rasch am Sun-Stand vorbei, um von unseren merkwürdigen Phänomenen zu berichten und hoffentlich einen guten Tipp zu erhalten. Allerdings war das Gespräch unerwartet schnell zu Ende. Wenn wir einen Supportvertrag für 240 US-Dollar im Jahr - oder am besten den Premium-Support für 1040 US-Dollar - abschließen würden, bekämen wir jede Hilfe die wir bräuchten. Außerdem könnten wir ja einen Sun Fire Server erwerben wenn wir wollen. Wir wollen nicht...

Hilfe bekamen wir weiterhin aus zwei Quellen. Einmal von unserem Community-Mitglied Mogul, zum anderen von Jörg Möllenkamp, der als Beschäftigter bei Sun einen <a href="http://www.c0t0d0s0.org" TARGET="_blank">Blog</a> u.a. zum Thema Solaris betreibt und sich unsere crashdumps genauer angesehen hat. Über diese Quellen mussten wir zum Beispiel auch erfahren, dass es von Sun noch wesentlich mehr Patches gibt, als die ohnehin schon zahlreichen, die wir bereits eingespielt hatten. Allerdings bleiben die normalerweise den zahlenden Kunden vorbehalten. Erste Zweifel am Support-Modell von Sun machten sich breit. Kostenpflichtiger Support für individuelle Beratung oder für die Bereitstellung spezieller Features, ok. Aber zahlen für kritische Updates, damit das OS überhaupt stabil zu betreiben ist? Das war nicht mit unserer Auffassung von Support zu vereinbaren. Wie der Zufall es will gab es in diesem Pool einen weiteren Patch, der das Problem beheben sollte. Über inoffizielle Kanäle haben wir ihn auch zum Testen erhalten. Nach drei Tagen aber wieder das selbe Problem: Kernel Panic.

Das war der Punkt, an dem wir endgültig die Nase voll hatten. Seit Ende Februar hatten wir wegen der fortwährenden Probleme mit dem System mehr als 4.500 km zurückgelegt. Mehr als 600 Mann-Stunden hatte das Projekt seitdem verschlungen. Wohlgemerkt neben der normalen Arbeit, denn Planet 3DNow! ist für alle Beteiligten lediglich ein - wenn auch inzwischen sehr zeitaufwändiges - Hobby. Die 4-tägige Downtime Anfang März hat den grünen Planeten zudem bis heute fast ein Drittel an Besuchern gekostet und im Forum machte sich selbst bei den Stammbesuchern langsam Unmut breit über die zahlreichen Ausfälle durch sowohl die Abstürze, als auch die geplanten Downtimes beim Einspielen von Patches oder beim Reparieren von bei Abstürzen zerschossener Dateien. Dass unsere Frauen in den letzten Tagen auffällig häufig in den gelben Seiten unter "Scheidungsanwälte" blätterten, sei nur nebenbei erwähnt.

Nein, irgendwann einmal musste Schluss sein. Die zwei Hauptgründe für die Wahl von Solaris war das ZFS-Dateisystem sowie die unerschütterliche Stabilität, die dem Betriebssystem nachgesagt wird. Dieser Nimbus jedoch war bei uns auf alle Zeit zerstört, das Vertrauen dahin. Wir ertappten uns schon dabei im Dreischicht-Betrieb Serverwachen zu halten, damit wenigstens einer der Admins online ist, um zerfetzte Dateien wiederherstellen zu können, wenn der Server eine seiner Panik-Attacken hinter sich hatte. Mag sein, dass Solaris 10 auf Sun-Servern mit einer schmalen Bandbreite an eingesetzter Hardware und allen kostenpflichtigen Patches tatsächlich völlig problemlos arbeitet, auf unserer Maschine jedoch war das OS rückblickend ein teurer und zeitaufwändiger Mißgriff. Die einzige Möglichkeit das ZFS-Dateisystem als Feature nicht zu verlieren, wäre gewesen von Solaris 10 auf OpenSolaris zu wechseln. Aber ob das die Probleme auf unserer Maschine behoben hätte, konnte niemand mit Bestimmtheit vorher sagen. Nein, das Wichtigste, das wir nun brauchten, war Stabilität, um Vertrauen in den Server, bei den Besuchern und Besucher an sich zurück zu gewinnen, um im Reallife wieder ein Leben neben Planet 3DNow! führen zu können und vor allem um wieder ruhigen Gewissens ins Bett gehen zu können ohne fürchten zu müssen, dass am nächsten Tag ein weiterer Tiefflug nach Frankfurt bevorstehen könnte, um das System wiederzubeleben. Daher haben wir am zurückliegenden Wochenende in einem weiteren (und hoffentlich für lange Zeit letzten) Frankfurt-Aufenthalt Solaris 10 wieder vom Server geworfen und ein aktuelles Gentoo-Linux AMD64 installiert. Mit der Bekanntgabe dessen wollten wir allerdings warten bis sicher war, dass wir Solaris 10 nicht unrecht tun, dass die Probleme nicht etwa doch trotz aller bestandener Hardware-Stabilitätstests durch eine beim Upgrade beschädigte Komponente verursacht wurden. Wenig überraschend jedoch ist der Server seitdem wieder fromm wie ein Lamm.

Umso ärgerlicher ist unser Fehlschlag mit Solaris, da wir so gut vorbereitet wie noch nie in dieses Projekt gingen. Schon Wochen vor dem Upgrade lief Solaris auf einem Spiegelserver im Testbetrieb - völlig ohne Probleme wie es schien. Dort wurde auch die Konfiguration verfeinert, die Applikationen wurden installiert und angepasst - alles um eventuellen Problemen auf die Spur zu kommen, ehe das System auf der Produktiv-Maschine landet. Eines allerdings fehlte auf dem Testserver natürlich: fortwährende(r) und praxisbezogene(r) Last/Traffic über Tage hinweg.

So verlassen wir Solaris mit einem lachenden und einem weinenden Auge. Mit einem lachenden logischerweise, weil der Server nun mit Linux endlich wieder stabil arbeitet, weil wir nun wieder Anwendungen einsetzen können, die uns mit Solaris verwehrt waren (eaccelerator oder sämtliche Distributed Computing Anwendungen, bei denen P3D mit einem Team mitmischt), mit einem weinenden allerdings, da Solaris in den Tagen zwischen den Abstürzen sein Potenzial eindrucksvoll angedeutet hat. Eine traumhaft niedrige Systemlast verglichen mit Gentoo zum Beispiel, obwohl Gentoo in der Linux-Welt bereits als die mit am besten optimierte Distribution gilt. Oder die beispielhafte Performance des ZFS-Dateisystems, das lesend vom Raid-1 eine Readspeed von über 200 MB/s zu Stande brachte, während wir mit ext3 in der selben Konfiguration unter Linux nun wieder bei 90 MB/s dümpeln. Aber sei's drum.

Bedanken möchten wir uns an dieser Stelle noch bei Mogul, der uns alle Hilfe anbat, die er uns geben konnte, bei Jörg Möllenkamp der einerseits bei der crashdump-Analyse half, andererseits sich als Sun-Mann in seinem Blog aber auch leider zu der ein oder anderen unnötigen geringschätzigen Bemerkungen über unsere Admins hinreißen ließ, nachdem erste Kritik am OS bzw. am Supportmodell laut wurde; bei unseren beiden technischen Administratoren D'Espice und tomturbo, die in den letzten 6 Wochen scheinbar einen Weg gefunden haben die Raumzeit zu krümmen, um all die Zeit, die der Server für sich beanspruchte, irgendwo unterzubringen und natürlich bei unseren Besuchern, die nun wahrlich mehr als genug Geduld aufbringen mussten, wenn das Boot mal wieder im Trockendock stand und uns trotzdem (zumindest in der Mehrheit) nicht den Rücken kehrten. So kann auf dem grünen Planeten nun hoffentlich wieder Normalität einkehren.
 
Eine traumhaft niedrige Systemlast verglichen mit Gentoo zum Beispiel, obwohl Gentoo in der Linux-Welt bereits als die mit am besten optimierte Distribution gilt. Oder die beispielhafte Performance des ZFS-Dateisystems, das lesend vom Raid-1 eine Readspeed von über 200 MB/s zu Stande brachte, während wir mit ext3 in der selben Konfiguration unter Linux nun wieder bei 90 MB/s dümpeln. Aber sei's drum.
Öhm, mit wieviel Platten arbeitet ihr momentan im RAID? 200 MB/s deuten auf mindestens drei eher vier Platten hin. Irgendwie zweifelt es mir hier an den Messwerten.
Das möchte ich auch auf die Systemlast übertragen. Seid ihr sicher, dass die Messwerte vergleichbar sind? Nach meinen letzten Kenntnissen ist Linux seit NPTL Solaris in der Task- (Thread-)Verwaltung überlegen.
Was ZFS angeht, habe ich mich an anderer Stelle schon hinreichend abwertend geäußert. Dass es aber ext3 in der Performance um mehr als 100% überlegen ist, kann ich noch nicht so recht glauben. Sicher, öffentliche Benchmarks zeigen, dass es schnell ist. Aber ein derartiger Unterschied lässt mich erstmal unterschiedliche Messgrundlagen vermuten.
 
Danke für die ausführliche Darlegung euer unermütlichen Arbeit.
Viele haben sich schon gefragt warum, keine richtigen Infos rauskamen, aber wenn man sich den Artikel genau durchliesst weiss man warum ihr zum Schluss gewartet habt.

Super Arbeit, und hoffen wir, dass ihr alle noch verheiratet seid.;D
 
Öhm, mit wieviel Platten arbeitet ihr momentan im RAID? 200 MB/s deuten auf mindestens drei eher vier Platten hin. Irgendwie zweifelt es mir hier an den Messwerten.
Die Messungen wurden sowohl unter Solaris, als auch unter Linux mit dem Befehl "hdparm -tT [DEVICE]" durchgeführt. Gemessen wurde dabei nur die Performance der beiden mirrored 15K SCSI Platten für die MySQL-DB. 90 MB/s ist dabei in etwa die Geschwindigkeit, die eine einzelne 15K-Platte an sequenzieller Lesegeschwindigkeit zustande bringt, 200 MB/s deuten auf zwei Platten hin. Wahrscheinlichste Erklärung: ext3 liest von beiden Platten parallel das Gleiche und checkt so die Integrität auch beim Lesen noch einmal. Damit ist die Geschwindigkeit nicht höher, als mit nur einer Platte. ZFS dagegen scheint sich beim Lesen auf seine integrierte Fehlerkorrektur zu verlassen und liest die Daten nicht einfach stumpf parallel, sondern wie ein Raid-0. Die Hardware (Laufwerke, Verkabelung, Controller) war in beiden Fällen identisch.
 
Tja, hat nicht sollen sein.

Hoffen wir das das Boot wieder zuverlässig läuft wie vor dem Abenteuer Solaris.

Solaris an sich mag gut sein, aber es ist wohl für die "freie Wildbahn" wohl doch nicht so geeignet :(

Ich danke dem Team jedenfalls für seinen grossartigen Einsatz!
(und sollte ich mal ein paar Millionen im Lotto gewinnen sponsere ich euch gerne ;D)
 
@Nero: Kann ich nicht so recht glauben, dass das am Dateisystem liegt. Wenn schon ein Teil der Software entscheidet ob doppelt oder verteilt gelesen wird, dann der Treiber/Kernel, aber sicher nicht der Code für das Dateisystem. Da wäre jetzt ein bench von ext3 unter Solaris oder ZFS unter Linux interessant.

Transferrate ist ja schön und gut, aber mal ehrlich, was habt ihr auf dem System wo mehr als 2-3 MB am Stück gelesen werden ?
Läuft eure DB komplett im Ram oder wird da noch lesend auf die Platten zugegriffen ?
 
ich hatte sowas schon geahnt,

dank auch an D'Espice und tomturbo und auch an Mogul

für ihre Super Arbeit hier

aber das Boot läuft zur Zeit Super, und auch der Speed ist Super.

wollen hoffen das das alles so bleibt.

mfg
Sir Ulli
 
Egal welche "Pro´s" etwas dazu sagen, so war es sicherlich die korrekte Entscheidung. :)
So ein privates Projekt ist eben hinsichtlich seiner zeitlichen und finanziellen Mittel begrenzt.
Ich weiss echt nicht wie ihr das geschafft habt immer wieder hin und her zu fahren.

Und da sieht man mal wieder die Tücken des Web2.0 (hier in Form des Blog), jeder der meint die Weißheit mit Löffeln gefressen zu haben posaunt sein Ding raus egal wie unpassend das ist. Man muss den Support eben auch bezahlen können.
Also am besten ignorieren was da geredet wird (gilt auch für mich, ich reg mich über die Sprüche da grad nur tierisch auf)(().

Und an eure Frauen/Freundinnen beste Grüße und vielen Dank, dass sie euch nicht komplett den Kopf abgerissen haben (denn leben tut ihr ja noch).
Schließlich wollen die ihre Freunde/Männer auch nochmal zu Gesicht bekommen.
"Ach guck mal da kommt dein Vater ... der ist vor 5 Jahren los gegangen um Solaris 10 zu installieren." ;D
 
Zuletzt bearbeitet:
Ich schreib ja selten einen Kommentar zu einer News, aber hier muss ich mal aktiv werden:

Ich kann nur ein dickes
DANKE
sagen!

Danke an euch und an eure Frauen, dass sie so viel Geduld mit euch hatten! *massa*
Und wie's aussieht, war es gut, dass ihr vor der (Zurück-)Umstellung auf Linux nix gesagt habt ;)

MfG Dalai

PS: Die Sonne ist zwar jetz untergegangen, aber nun kann der Tux wieder rumhüpfen ;D
 
Zuletzt bearbeitet:
Die Messungen wurden sowohl unter Solaris, als auch unter Linux mit dem Befehl "hdparm -tT [DEVICE]" durchgeführt. Gemessen wurde dabei nur die Performance der beiden mirrored 15K SCSI Platten für die MySQL-DB. 90 MB/s ist dabei in etwa die Geschwindigkeit, die eine einzelne 15K-Platte an sequenzieller Lesegeschwindigkeit zustande bringt, 200 MB/s deuten auf zwei Platten hin. Wahrscheinlichste Erklärung: ext3 liest von beiden Platten parallel das Gleiche und checkt so die Integrität auch beim Lesen noch einmal. Damit ist die Geschwindigkeit nicht höher, als mit nur einer Platte. ZFS dagegen scheint sich beim Lesen auf seine integrierte Fehlerkorrektur zu verlassen und liest die Daten nicht einfach stumpf parallel, sondern wie ein Raid-0. Die Hardware (Laufwerke, Verkabelung, Controller) war in beiden Fällen identisch.

Also zum einen ist mir noch keine Platte untergekommen, welche 90 MB/s an sequentieller Leseleistung bringt. Gut 70 MB/s war da das höchste. Ok, das muss nicht aussagekräftig sein, da ich schon länger keine Platten mehr getestet habe. Kann durchaus sein, dass aktuelle Platten diese Leistung bringen. Obwohl ich das bezweifle.
Aber der Test mit hdparm geht vollkommen am Dateisystem vorbei. Der misst wirklich nur die rohe Leistung der Platte. Insofern kann ext3 oder ZFS hier garkeinen Einfluss haben. Insofern habe ich den Eindruck, dass hier ein Cache unter Solaris Einfluss genommen hat, der unter Linux nicht existent ist bzw. umgangen wird. Nach meiner Erfahrung (und da habe ich jetzt doch einige), ist der beste Test für ein Dateisystem, viele Dateien zu bewegen, je nach Anforderungsprofil. Ich habe da jetzt reichlich Tests mit den unter Linux zur Verfügung stehende FSs hinter mir. Und ebenso habe ich dazu entsprechend Feedback von den FS-Entwicklern bzw. -programmierern.
Dass das deutlich komplexere ZFS eine so großen Vorsprung gegenüber ext3 hat, kann ich mir absolut nicht vorstellen. Ein 100%iger Zuwachs ist einfach unrealistisch. Ich werde das hier auch gerne nochmal nachprüfen, aber ich glaube nicht, dass sich die Zahlen bestätigen.

PS: Ach ja, ich vergaß schon im erstem Posting meine Dank an D'Espice, tomturbo und den Rest der Crew. Ich weiß ja selber, welchen Aufwand so ein Projekt mit sich bringt. (Gruß an Martin, welcher mich damals aus der Jugendstunde (Kirche) meiner Freundin damals riss. ;) )
 
Zuletzt bearbeitet:
Schade, dass es nicht hatte sollen sein, aber ist wohl die bessere Lösung. Lieber ein paar Knoten weniger als bei Ak voraus möglich, dafür nicht alle 2 Tage nen neuen Kessel.
In diesem Sinne noch mal ein riesen Danke ans Team für die ganze Arbeit und v.a. die Zeit. Schenkt euren Frauen mal nen großen Blumenstrauß oder sowas ;D für die ganze Geduld.
 
Kurzgesagt: DANKE!

Bis denne!
 
Irgendwie hatte ich auch schon damit gerechnet muss ich sagen.
Zwar lief es, aber dann doch mehr schlecht als Recht. Ob wir als die normalen User wirklich viel von Solaris gemerkt hätten sie mal dahingestellt, aber es ist schon schade das dieses Experiment dann doch nicht geglückt ist.

Auf jeden Fall mal ein riesen DANKESCHÖN an all die schier unermüdlichen Helfer!!!
 
Ein kleiner Kommentar zur Leistung des Dateisystems:

Der Test bestand mitnichten darin, mit hdparm die Leistung zu messen, da hat sich Nero24 leider geirrt. Den hdparm Test haben wir natürlich auch durchgeführt und da lag Solaris immer noch vor Linux, allerdings nicht mehr so eindeutig. Der Grund ist vermutlich der bessere Treiber im Kernel.

Der obige Test wurde auf folgende Art und Weise durchgeführt:
  1. Mittels dd if=/dev/hda1 of=/pfad/zum/slice/datei eine 10GB große Datei anlegen (HDA1 symbolisch für unser Backup-RAID1) - Messung der Schreibleistung mittels iostat
  2. Neu starten um den Cache zu umgehen
  3. Diese Datei nach /dev/null kopieren und gleichzeitig mit iostat den Plattendurchsatz messen

Dabei wird weder der Plattencache noch die Rohleistung gemessen, sondern die reine Vergleichsleistung zweier Dateisysteme. Der Test hat ergeben: Schreibleistung auf das 2x15k RAID1: ~70 MB/s. Leiseleistung vom 2x15k RAID1: ~95 MB/s
Unter Solaris/ZFS waren die Werte ganz anders: ~65 MB/s schreibend, fast konstant über 200 MB/s lesend (mit Ausschlägen nach unten und oben, Spitze waren 227 MB/s)

Und noch ein kleines Schmankerl: Unter Solaris war die load zu den Stoßzeiten (also zw. 18-24 Uhr) nur extrem selten mal über zwei, im Schnitt bei 1,5. Unter Gentoo geht die load schon nachmittags auf zwei und Abends dann drüber - derzeit 2.70, 2.60, 2.91
 
Nun ja schade eigentlich. Ich muß zugeben keine wirkliche Ahnung in dem Bereich zu haben, aber Solaris klingt immer gleich nach einem großen Batzen Professionalität. Aber sei's drum!

Trotzdem einen großen Dank an unsere Einsatzgruppe die dafür sorgt, dass wir unsere Freizeit wieder mit p3dnow verbringen können!

MfG der BarBart
 
trotzdem einen großen Dank an unsere Einsatzgruppe die dafür sorgt, dass wir unsere Freizeit wieder mit p3dnow verbringen verplempern (müsste das wohl heissen ;D, Die Redaktion ) können!

*suspect* ;D
 
Ein kleiner Kommentar zur Leistung des Dateisystems:

Der Test bestand mitnichten darin, mit hdparm die Leistung zu messen, da hat sich Nero24 leider geirrt. Den hdparm Test haben wir natürlich auch durchgeführt und da lag Solaris immer noch vor Linux, allerdings nicht mehr so eindeutig. Der Grund ist vermutlich der bessere Treiber im Kernel.

Der obige Test wurde auf folgende Art und Weise durchgeführt:
  1. Mittels dd if=/dev/hda1 of=/pfad/zum/slice/datei eine 10GB große Datei anlegen (HDA1 symbolisch für unser Backup-RAID1) - Messung der Schreibleistung mittels iostat
  2. Neu starten um den Cache zu umgehen
  3. Diese Datei nach /dev/null kopieren und gleichzeitig mit iostat den Plattendurchsatz messen

Dabei wird weder der Plattencache noch die Rohleistung gemessen, sondern die reine Vergleichsleistung zweier Dateisysteme. Der Test hat ergeben: Schreibleistung auf das 2x15k RAID1: ~70 MB/s. Leiseleistung vom 2x15k RAID1: ~95 MB/s
Unter Solaris/ZFS waren die Werte ganz anders: ~65 MB/s schreibend, fast konstant über 200 MB/s lesend (mit Ausschlägen nach unten und oben, Spitze waren 227 MB/s)
Nach meiner Erfahrung ist das leider immer noch nicht aussagekräftigt. Ich habe sowohl mit dd als auch mit cp getestet (unter Linux), und die Werte wichen teilweise eklatant voneinander ab. Bei nächster Gelegenheit werde ich die Tests auch auf Solaris ausweiten. Aber ich kann mir nicht vorstellen, dass ZFS dermaßen gut gegenüber ext abschneidet. Einerseits aus Erfahrung mit den Test gegenüber JFS und XFS, welche beide für sich besser Performance in Anspruch nehmen, andererseits überhaupt im Design der einzelnen FS. ZFS ist ebenso wie XFS oder JFS deutlich komplexer als ext. Das schlägt sich zwangsläufig in der Performance nieder.
Und schlussendlich erscheinen mir 200 MB/s für zwei Platten einfach nicht realistisch.

Und noch ein kleines Schmankerl: Unter Solaris war die load zu den Stoßzeiten (also zw. 18-24 Uhr) nur extrem selten mal über zwei, im Schnitt bei 1,5. Unter Gentoo geht die load schon nachmittags auf zwei und Abends dann drüber - derzeit 2.70, 2.60, 2.91
Das weckt natürlich Interesse nach mehr. Wobei für mich immer noch die Frage ist, wie die load auf dem jeweiligen System ermittelt wird. ;)
 
Der Test bestand mitnichten darin, mit hdparm die Leistung zu messen, da hat sich Nero24 leider geirrt. Den hdparm Test haben wir natürlich auch durchgeführt und da lag Solaris immer noch vor Linux, allerdings nicht mehr so eindeutig. Der Grund ist vermutlich der bessere Treiber im Kernel.

Der obige Test wurde auf folgende Art und Weise durchgeführt:
...
Ah, ok, das wusste ich nicht, was Ihr noch so alles getestet habt *suspect* Aber wenn die 200 MB/s aus einem Praxistest stammen - umso besser :)
Also zum einen ist mir noch keine Platte untergekommen, welche 90 MB/s an sequentieller Leseleistung bringt. Gut 70 MB/s war da das höchste. Ok, das muss nicht aussagekräftig sein, da ich schon länger keine Platten mehr getestet habe.
Schon eine aktuelle 7200/min SATA2-Platte mit Perpendicular Recording liegt hier über 70 MB/s. Die bei uns eingesetzten SCSI-Platten drehen aber mehr als doppelt so schnell :o Insofern liegen die 90 MB/s durchaus im realistischen Bereich.

Im Endeffekt ist es mir auch egal, ob der Zuwachs vom Kernel, vom Filesystem oder von einem ausgeklügelten Prefetch-Algorithmus von Solaris kommt. Bei einem synthetischen Test wie hdparm kann man's vielleicht noch auf einen Fehler schieben. Wenn aber riesige Dateien - wie ich eben erfahren habe ;) - nach einem Neustart doppelt so schnell von HDD nach dev/null kopiert werden, dann will das schon etwas heißen.

Aber was soll's. ZFS ist Geschichte auf dem Boot 2.1 und ein Alpha-Projekt wie ZFS unter FUSE/Linux werden wir auf einem Produktiv-Server ganz sicher nicht einsetzen :o Derzeit würde ich FAT16 einsetzen, wenn das die einzige Möglichkeit wäre bis Ende nächsten Jahres nicht mehr nach Frankfurt jetten zu müssen ;)
 
Schon eine aktuelle 7200/min SATA2-Platte mit Perpendicular Recording liegt hier über 70 MB/s. Die bei uns eingesetzten SCSI-Platten drehen aber mehr als doppelt so schnell :o Insofern liegen die 90 MB/s durchaus im realistischen Bereich.
Also mich macht die pure Rohleistung von 100 MB/s schon irgendwo stutzig. Natürlich hat die Plattentechnologie in den letzten Jahren nicht geschlafen. Aber ihr habt hier SCSI-Platten vermessen. Und die sind technologisch generell sehr konservativ aufgestellt. Sowas wie perpendicular recording sind da noch böhmische Dörfer. Das soll heißen, was die Dauertransferraten angeht, hängen SCSI-Platten den Consumer-Produkten eher nach, als sie vorraus sind. Liegt ganz einfach an der geringeren Datendichte auf den Plattern. 200 MB/s bringen nichtmal unsere Storage-Arrays. Und so eine EVA ist schon verdammt dick aufgestellt, auch wenn sie von mehreren Nutzern gleichzeitig beansprucht wird.

Im Endeffekt ist es mir auch egal, ob der Zuwachs vom Kernel, vom Filesystem oder von einem ausgeklügelten Prefetch-Algorithmus von Solaris kommt. Bei einem synthetischen Test wie hdparm kann man's vielleicht noch auf einen Fehler schieben. Wenn aber riesige Dateien - wie ich eben erfahren habe ;) - nach einem Neustart doppelt so schnell von HDD nach dev/null kopiert werden, dann will das schon etwas heißen.
Eben das bezweifle ich. Mir klingt das sehr nach Caches. Und die halten nur so lange, wie RAM vorhanden ist. Danach müssen die auch wieder an die Platten, und da bremst immer das Dateisystem.

Aber was soll's. ZFS ist Geschichte auf dem Boot 2.1 und ein Alpha-Projekt wie ZFS unter FUSE/Linux werden wir auf einem Produktiv-Server ganz sicher nicht einsetzen :o Derzeit würde ich FAT16 einsetzen, wenn das die einzige Möglichkeit wäre bis Ende nächsten Jahres nicht mehr nach Frankfurt jetten zu müssen ;)
Naja, wieso hier unbedingt auf ext gesetzt werden musste, erschließt sich mir nicht so ganz. Ok, es mag bei kleineren Datenmenge performanter als die Alternativen (JFS und vor allem XFS) sein, aber das bedeutet beim nächsten Plattenupgrade auf jeden Fall auch wieder eine längere Auszeit. XFS hätte ebenso wie ZFS eine Erweiterung im laufenden Betrieb ermöglicht.
 
Naja, wieso hier unbedingt auf ext gesetzt werden musste, erschließt sich mir nicht so ganz. Ok, es mag bei kleineren Datenmenge performanter als die Alternativen (JFS und vor allem XFS) sein, aber das bedeutet beim nächsten Plattenupgrade auf jeden Fall auch wieder eine längere Auszeit. XFS hätte ebenso wie ZFS eine Erweiterung im laufenden Betrieb ermöglicht.
Die Begründung war, dass das eine der beiden (XFS?) mit der Zeit sehr langsam wird und bei dem anderen (JFS?) einfach die Langzeiterfahrung fehlt.
 
XFS soll in der tat stärker fragmentieren als das klassische ext3 so weit mir bekannt.
JFS... hm, darüber weiss ich jetzt auch nicht bescheid.

(ReiserFS ist sowieso für Tonne, ab einem gewissen Punkt fragmentiert das wie sau...)

ext3 war schon die richtige Entscheidung, denke ich.
 
XFS soll in der tat stärker fragmentieren als das klassische ext3 so weit mir bekannt.

Nein, tut es nicht. In der Tat fragmentiert XFS von allen unter Linux verfügbaren Dateisystemen am wenigsten. Dazu skaliert es als einzigstes FS sowohl mit der Größe des Devices als auch mit der Anzahl der Prozessoren.
 
Dann hat mir entweder jemand unsinn erzählt, oder du weisst es auch nicht sicher.
Ich selber nutze nach wie vvor ext3.
 
Zurück
Oben Unten