[Erledigt, nicht geklärt] SW-Raid auf S-ATA- lahm!

    Yohoo!


    Habe ja nun wirklich schon einiges an Erfahrung mit Software-RAID, als auch mit S-ATA.


    Situation:
    Ein Dell SC1425 S-ATA Server (2x Xeon 2,8, 2GB RAM, 2x S-ATA Ports)
    Zwei S-ATA Seagate 160GB Platten ST 3160287AS


    Jetzt habe ich ein SW-RAID-1 (Mirror) mit 130GB eingerichtet.


    Wie üblich fängt das SW-Raid ja nach Einrichtung mit dem Synchronisieren an. Was mich dabei aber intensivst wundert:


    Das macht er seit 24 Stunden und ist jetzt bei exakt 59,6%! Für mein 500GB RAID-5 (ok, SCSI) hat ein Athlon 1100er nicht solange gebraucht!


    Hat jemand eine Ahnung, wie man da feststellen könnte, was da los ist? Das Modul für den S-ATA ist libata und ata_piix, die Platten sind unter /proc/scsi/scsi zu finden.


    Hilfe wird gerne gesehen!

    Glotze: yaVDR (ASRock Q1900M, 4GB RAM, DD Cine S2 V6.5, ZOTAC GT630 (Rev. 2)
    Server: HP ProLiant MicroServer G8, VMware ESXi 5.5 :P

    Einmal editiert, zuletzt von knebb ()

    Zitat

    Habe ja nun wirklich schon einiges an Erfahrung mit Software-RAID


    Ei sowas - was lesen meine müden Äuglein ...
    Isch dachte, Du bist überzeugter SW-Raid-Gegner ?(


    Bei mir hat's auch so angefangen und jetzt sind die Controller rausgeflogen.
    Statt einem Promise hat's jetzt 3 Highpoint gegeben - und es flutscht wieder :rolleyes:

    Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

    Zitat

    Original von geronimo
    Isch dachte, Du bist überzeugter SW-Raid-Gegner ?(


    HAb' ich nie gesagt. HAb' nur gesagt, daß HW-Raid besser ist und nach Möglichkeit zu bevorzugen ist.


    Wenn's aber nicht anders geht und der S-ATA Controller zwar einen RAID-Modus hat, dieser aber von Linux nicht unterstützt wird :(


    Und: man muß halt immer noch unterscheiden zwischen "richtigem" HW-Raid und "Treiber-HW-Raid" (das ja eigentlich nix anderes als SW-Raid ist).


    Die Prioritäten sind eindeutig:
    1. HW-Raid (richtiges!)
    2. SW-Raid
    3. "Pseudo-Treiber-HW-Raid"

    Glotze: yaVDR (ASRock Q1900M, 4GB RAM, DD Cine S2 V6.5, ZOTAC GT630 (Rev. 2)
    Server: HP ProLiant MicroServer G8, VMware ESXi 5.5 :P

    *Hochschieb*


    Ist mir wichtig, soll mit Serverhousing mein Mail-, Web- und Sonstiges-Server werden.


    Gibt's brauchbare Plattenperfomanztools?


    Wie kann ich den Durchsatz messen?

    Glotze: yaVDR (ASRock Q1900M, 4GB RAM, DD Cine S2 V6.5, ZOTAC GT630 (Rev. 2)
    Server: HP ProLiant MicroServer G8, VMware ESXi 5.5 :P

    Full_ack:
    Link?


    Zitat

    Original von tüddelkopp
    Ich lese in diesem Zusammenhang immer von "Bonnie++"


    Hmmm.. bonnie kenne ich. Hat den Nachteil, daß man den Cache nicht ausschalten kann. Und da die Kiste 2GB RAM hat ist das ein großer Nachteil :) Vielleicht ist das ja bei bonnie++ nicht mehr so. Werde mal prüfen.


    Danke für die Tips und ich melde micht nochmal ;D

    Glotze: yaVDR (ASRock Q1900M, 4GB RAM, DD Cine S2 V6.5, ZOTAC GT630 (Rev. 2)
    Server: HP ProLiant MicroServer G8, VMware ESXi 5.5 :P

    Die schwache Performance ist nicht normal. Ich habe lange RAID5 mit drei und vier (aktiven) Platten zu je 120GB verwendet, jetztRAID1 mit zwei Platten zu je300GB. Der Controller ist ein Promise PCI mit 4 SATA-Anschlüssen, der Treiber libata (um sich das Initrd-Gedönse zu sparen). Die Performance mit SW-RAID ist gut. Einzig die Reaktion auf defekte SATA-Kabel ist schlecht, da ist ein RAID5 nicht sicher.
    Eine komplette Synchronisation benötigt durchaus Stunden, aber nicht 24.

    Zitat

    Original von randy
    naja, aber ein hardwareraid ist auch ned viel schneller :)


    Zumal es bei RAID1 auch nicht primär auf eine Performance-Steigerung ankommt, sondern auf die Ausfallsicherheit.


    Ich hatte das schonmal irgendwo geschrieben:


    Wer meint, RAID ist pauschal besser, einfach weil es sich "geil" anhört und in Mode ist, dem sei verziehen: "Denn sie wissen nicht, was sie tun."


    Aber back to Topic:


    Zitat


    so paar terabyte im mirror syncen dauert auch mal kurz nen tag. wobei bei einem
    "plain blocklevel copy" (sancopy) etwa 400gb/stunde durchgehen.


    Ist mir alles klar. Bei meinem SCSI-Hardware-Raid 5 dauert das syncen von 8x50GB Platten auch ein paar Stunden.


    Trotzdem sind 2,5 Tage Sync für 140GB S-ATA definitiv zu lange!


    Habe jetzt keine Lust gehabt, länger nach einem Fehler zu suchen oder die Ausgaben von iozone intensivst auszuwerten und habe nach Windows-Manier einfach neu installiert.


    Und siehe da: plötzlich dauert der Sync gerade mal ca. 1h! Den einzigen Unterschied, den ich feststellen konnte , ist der, daß in der Modulliste (lsmod) hinter dem Modul ata_piix jetzt ein "[permament]" steht. Was immer das auch zu bedeuten hat. :rolleyes:


    Wie auch immer. Teil läuft jetzt gut (Suse Linux Enterprise Server 9 mit x64) 8), jetzt kann er bald ans Netz gehen. Braucht noch jemand Webspace? ;D

    Glotze: yaVDR (ASRock Q1900M, 4GB RAM, DD Cine S2 V6.5, ZOTAC GT630 (Rev. 2)
    Server: HP ProLiant MicroServer G8, VMware ESXi 5.5 :P

    Einmal editiert, zuletzt von knebb ()


    wobei ich mich auf das raid5 bzw raid0 ausm post eins druebert bezogen hatte :)


    vorallem ist raid ja schon fast ne religion fuer sich, da es ja tausend verschiedene
    variationen gibt, fuer jede applikation eine. wobei ich meistens nur raid10 und raid5
    raidgruppen baue, aber dann je nachdem mit metaluns arbeite - "raid0" (stripping)
    von luns ueber mehrere raidgroups :)


    anyway - hauptsache es laeuft nun.


    -- randy

    knebb: Das ist die Hauptsache. Aber für diejenigen, die immer behaupten, man braucht Linux nie neu installieren ist das ja ein Schlag ins Gesicht. Ich habe in anderen Bereichen die gleiche Erfahrung gemacht. Das Problem lässt sich bestimmt auch ohne Neuinstallation lösen, aber nur mit t --> infty.


    Gruß


    Oliver

    Zitat

    Original von Full_ack
    Aber für diejenigen, die immer behaupten, man braucht Linux nie neu installieren ist das ja ein Schlag ins Gesicht.


    Stimmt. Nur ist ads bei Linux normalerweise eine Abstraktionsfrage. Der Profi bekommt eine System eigentlich immer zum Laufen. Wenn bei Win mal was zerschossen ist (z.B. manche Registry-Einträge) ist auch für die Registry-Kenner oft Schluß. Ist bei KDE was zerschossen, muß man notfalls halt maximal KDE neu installieren, aber nicht das ganze System. Und die Benutzereinstellungen bleiben dabei ja erhalten.


    Zitat

    aber nur mit t --> infty.


    Wass'n das?

    Glotze: yaVDR (ASRock Q1900M, 4GB RAM, DD Cine S2 V6.5, ZOTAC GT630 (Rev. 2)
    Server: HP ProLiant MicroServer G8, VMware ESXi 5.5 :P

    Hi,


    knebb:


    Schau doch bitte mal unter /proc/sys/dev/raid/speed_limit_min nach. Sollte dort noch der standardmässige Wert von 1000 stehen, einfach mal wesentlich erhöhen (ca. 100000 bis 200000). 1000kByte/s minimale Raidsyncgeschwindigkeit sind nicht unbedingt zeitgemäss bei Deinem System.


    ciao, Mathias

    Zitat

    Original von bidoba
    Schau doch bitte mal unter /proc/sys/dev/raid/speed_limit_min nach. Sollte dort noch der standardmässige Wert von 1000 stehen, einfach mal wesentlich erhöhen (ca. 100000 bis 200000).


    Danke, den /proc-Entry kannte ich so noch nicht.


    Zitat

    1000kByte/s minimale Raidsyncgeschwindigkeit sind nicht unbedingt zeitgemäss bei Deinem System.


    Klar, aber er hat ja nicht mal die 1000 erreicht. Er hat für 130GB 2,5 Tage benötigt!


    Die 1.000 ist normalerweise die _Minimalgrenze_, die garantiert ist, auch wenn das System mächtig viel zu tun hat. Es ist nicht die normalerweise übliche Geschwindigkeit. Insofern scheint es mir keine gute Idee zu sein, diese Grenze heraufzusetzen. Wenn andere Dienste I/O Leistung benötigen, kriegen sie keine, weil Min zu hoch steht.

    Glotze: yaVDR (ASRock Q1900M, 4GB RAM, DD Cine S2 V6.5, ZOTAC GT630 (Rev. 2)
    Server: HP ProLiant MicroServer G8, VMware ESXi 5.5 :P

    Hi nochmal,


    Zitat

    Original von knebb
    Klar, aber er hat ja nicht mal die 1000 erreicht. Er hat für 130GB 2,5 Tage benötigt!


    Die 1.000 ist normalerweise die _Minimalgrenze_, die garantiert ist, auch wenn das System mächtig viel zu tun hat. Es ist nicht die normalerweise übliche Geschwindigkeit. Insofern scheint es mir keine gute Idee zu sein, diese Grenze heraufzusetzen. Wenn andere Dienste I/O Leistung benötigen, kriegen sie keine, weil Min zu hoch steht.


    Richtig, das sollte eigentlich die Minimalgrenze unter hoher Systemlast sein. Eigentlich deshalb, weil ich just an letztem WE selbiges Phänomen erneut (schon vorher auf anderen Rechnern beobachtet) hatte. Rechner war/ist Dual Xeon 1,8GHz, 1GB Ram, 8x 160 GB als Raid 5. Syncgewschwindigkeit laut /proc/mdstat ca. 1100 bis 1200 kByte/s bei originialem Wert vom 1000 für speed_limit_min. Wohlbemerkt, es war keine weitere Systemlast vorhanden. Nach heraufsetzen auf 100000 ergab es eine realistische Geschwindigkeit von etwa 30 MByte/s. Entsprechendend änderte sich die Resynczeit von 2500 auf knapp 100 min.


    ciao, Mathias

    Zitat

    Original von bidoba
    Syncgewschwindigkeit laut /proc/mdstat ca. 1100 bis 1200 kByte/s bei originialem Wert vom 1000 für speed_limit_min.


    Ja, wie bei mir. Das angebliche Limit war knapp über 1.000.


    Zitat


    Nach heraufsetzen auf 100000 ergab es eine realistische Geschwindigkeit von etwa 30 MByte/s.


    Aha. Ist ja cool. Mit anderen Worten: In manchen Fällen unterschreitet der Sync die eigentliche Min-Grenze und läßt sich zu einer vernünftigen Geschwindigkeit durch ein (eigentlich unlogisches) Hochsetzen dieser Grenze überreden?


    Hmmm... hört sich nach Bug an. Kannst du das reproduzieren? Mein System hier ist ebenfalls ein Dual-Xeon 2,8 (HT deaktiviert) mit einem x64- Kernel.
    (SLES9)

    Glotze: yaVDR (ASRock Q1900M, 4GB RAM, DD Cine S2 V6.5, ZOTAC GT630 (Rev. 2)
    Server: HP ProLiant MicroServer G8, VMware ESXi 5.5 :P

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden