Hallo zusammen, gibt es eine Möglichkeit, den RAID-Level eines Systems im Nachhinein zu ändern? Hier läuft eine 11.0 auf einem 3ware 9650 mit RAID6. Es stecken sechs Platten im System, zwei Ports sind noch frei. Geht das, daß man im laufenden Betrieb die Ports 7 und 8 mit entsprechend großen Platten belegt, dort zeitweilig die Daten mit RAID1 oder 0 draufschaufelt, und dann das RAID6 in ein RAID5 verwandelt, und die Daten wieder dorthin zurückschaufelt? Ich merke nämlich, daß das RAID6 zum Flaschenhals wird, und denke, daß RAID5 da Verbesserung bringen würde. -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann schrieb:
Hallo zusammen,
gibt es eine Möglichkeit, den RAID-Level eines Systems im Nachhinein zu ändern? Hier läuft eine 11.0 auf einem 3ware 9650 mit RAID6. Es stecken sechs Platten im System, zwei Ports sind noch frei. .... Also bei Softraid könntest Du einfach ein paralleles Raid aufbauen und die Daten rüberschaufeln. Wie das bei dem 3ware ist, sollte die Bedienungsanleitung verraten. Jedenfalls würde ich keine Experimente mit Daten machen, die ich noch brauch.
Ich merke nämlich, daß das RAID6 zum Flaschenhals wird, und denke, daß RAID5 da Verbesserung bringen würde.
Bevor Du da was umbaust, solltest Du eine konkrete Performanceanalyse zu dem Thema und Deiner praktischen Anwendung machen! Wenn Du "denkst" (ist nicht persönlich sondern sachlich gemeint!) es könnte eine Verbesserung bringen.... Das sind mir einfach zu viele unbekannte in einem einzigen Satz. Gruß Axel -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Andre, Axel Birndt schrieb:
Andre Tann schrieb:
Hallo zusammen,
gibt es eine Möglichkeit, den RAID-Level eines Systems im Nachhinein zu ändern? Hier läuft eine 11.0 auf einem 3ware 9650 mit RAID6. Es stecken sechs Platten im System, zwei Ports sind noch frei. .... Also bei Softraid könntest Du einfach ein paralleles Raid aufbauen und die Daten rüberschaufeln. Wie das bei dem 3ware ist, sollte die Bedienungsanleitung verraten. Jedenfalls würde ich keine Experimente mit Daten machen, die ich noch brauch.
Also lt. Datasheet ( http://www.3ware.com/products/pdf/82911-AMCC-9650SE-Ger.pdf ) sollte das mischen von verschiedenen Raidleveln und Multivolumes möglich sein. Da ich es nicht ausprobieren kann würde ich vorschlagen mal an 3ware zu schreiben. "Die" sollten doch eine Anleitung o.ä. haben. Am Ende stehts in den FAQ drin ?? -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Axel Birndt, Dienstag, 14. Oktober 2008 08:52:
Bevor Du da was umbaust, solltest Du eine konkrete Performanceanalyse zu dem Thema und Deiner praktischen Anwendung machen!
Da hast Du wohl recht, und höchstwahrscheinlich kann man das noch besser machen, als ich es tat. Allerdings merke ich eben häufig, daß Speicher (16 GB) und Prozessor (8 Kerne, Frequenz... grad keine Ahnung...) nie voll ausgelastet sind. Dagegen stocken die Anwendungen (v.a. vmware-Maschinen) immer wieder, und das immer dann, wenn grad Last auf die Platten kommt. Und wenn IO-Last kommt, dann sehe ich in vmstat, daß die Zahl der Blocks out hochspringt, und für einige lange Sekunden bei diesem Maximalwert verbleibt. IIRC sind das ca. 6000 Blocks bei Aufruf von "vmstat 2". Sobald die Last wieder absinkt, läuft die Maschine wieder flüssig. Demgegenüber habe ich eine ganz ähnliche Maschine daneben stehen (AMD statt Intel), auch mit 6 Platten, aber RAID5. Und hier kriege ich 25000 Blocks weggeschrieben. Diese Maschine kommt auch viel seltener ins Stocken. Davon abgesehen kann diese Maschine auch viel schneller lesen. Mache ich ein dd if=/dev/sda of=/dev/null, und schaue dann mit vmstat 2 zu, dann ist die Zahl der Blocks in um ca. den Faktor 2-3 höher als bei der "Problemmaschine". Das waren eben meine Beobachtungen. Was kann ich da noch genauer/besser machen? Gruß. -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann wrote:
Axel Birndt, Dienstag, 14. Oktober 2008 08:52:
Bevor Du da was umbaust, solltest Du eine konkrete Performanceanalyse zu dem Thema und Deiner praktischen Anwendung machen!
Da hast Du wohl recht, und höchstwahrscheinlich kann man das noch besser machen, als ich es tat. Allerdings merke ich eben häufig, daß Speicher (16 GB) und Prozessor (8 Kerne, Frequenz... grad keine Ahnung...) nie voll ausgelastet sind. Dagegen stocken die Anwendungen (v.a. vmware-Maschinen) immer wieder, und das immer dann, wenn grad Last auf die Platten kommt.
Cachen ist das wirksamste, was man machen kann. In deinem Fall nutzt das OS den RAM als Cache für das Dateisystem, solange noch RAM frei ist, danach bricht die Performance zusammen, und du siehst das als Stehenbleiben der VMs. Hat dein Controller eine BBO? Das hilft enorm.
Und wenn IO-Last kommt, dann sehe ich in vmstat, daß die Zahl der Blocks out hochspringt, und für einige lange Sekunden bei diesem Maximalwert verbleibt. IIRC sind das ca. 6000 Blocks bei Aufruf von "vmstat 2". Sobald die Last wieder absinkt, läuft die Maschine wieder flüssig.
Demgegenüber habe ich eine ganz ähnliche Maschine daneben stehen (AMD statt Intel), auch mit 6 Platten, aber RAID5. Und hier kriege ich 25000 Blocks weggeschrieben. Diese Maschine kommt auch viel seltener ins Stocken. Davon abgesehen kann diese Maschine auch viel schneller lesen. Mache ich ein dd if=/dev/sda of=/dev/null, und schaue dann mit vmstat 2 zu, dann ist die Zahl der Blocks in um ca. den Faktor 2-3 höher als bei der "Problemmaschine".
Ich habe hier eine Windows 2003 Maschine mit einem 3Ware 9650, auf dem habe ich 8 Festplatten als RAID 10 angelegt, damit die IO-Vorgänge ohne die Stripe-Berechnungen ablaufen. Bonnie brachte dafür etwa 80-120 MB/s Schreibgeschwindigkeit und über 300 MB/s Lesegeschwindigkeit. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Sandy Drobic, Dienstag, 14. Oktober 2008 10:33:
Cachen ist das wirksamste, was man machen kann. In deinem Fall nutzt das OS den RAM als Cache für das Dateisystem, solange noch RAM frei ist, danach bricht die Performance zusammen, und du siehst das als Stehenbleiben der VMs.
Das sieht hier anders aus: Mem: 16634012k total, 12961280k used, 3672732k free, 544704k buffers Swap: 5245180k total, 0k used, 5245180k free, 12046524k cached Also: von 16 GB nutzt die Kiste nur 12,9 GB. Zum Cachen wäre also noch genug da. Ferner: # uptime 11:50am an 23 Tage 1:53, 1 Benutzer, Durchschnittslast: 0,47, 0,50, 0,46 Inzwischen hätte der Cache also schon vollaufen können. Ist er aber nicht, weil immer noch genug RAM da ist.
Hat dein Controller eine BBO? Das hilft enorm.
# /opt/AMCC/CLI/tw_cli //08071000-vmhost3> show Ctl Model (V)Ports Drives Units NotOpt RRate VRate BBU ------------------------------------------------------------------------ c2 9650SE-8LPML 8 6 2 0 1 1 OK ...oops, NotOpt = 1. Das war gestern noch anders...
Ich habe hier eine Windows 2003 Maschine mit einem 3Ware 9650, auf dem habe ich 8 Festplatten als RAID 10 angelegt, damit die IO-Vorgänge ohne die Stripe-Berechnungen ablaufen.
Bonnie brachte dafür etwa 80-120 MB/s Schreibgeschwindigkeit und über 300 MB/s Lesegeschwindigkeit.
OK: # bonnie Bonnie 1.4: File './Bonnie.2840', size: 104857600, volumes: 1 Writing with putc()... done: 22452 kB/s 35.2 %CPU Rewriting... done: 24414 kB/s 3.1 %CPU Writing intelligently... done: 25065 kB/s 2.4 %CPU Reading with getc()... done: 54403 kB/s 100.1 %CPU Reading intelligently... done: 2148462 kB/s 100.7 %CPU Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 080710 1* 100 22452 35.2 25065 2.4 24414 3.1 54403 1002148462 101 113227.8 170 -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann wrote:
Sandy Drobic, Dienstag, 14. Oktober 2008 10:33:
Cachen ist das wirksamste, was man machen kann. In deinem Fall nutzt das OS den RAM als Cache für das Dateisystem, solange noch RAM frei ist, danach bricht die Performance zusammen, und du siehst das als Stehenbleiben der VMs.
Das sieht hier anders aus:
Mem: 16634012k total, 12961280k used, 3672732k free, 544704k buffers Swap: 5245180k total, 0k used, 5245180k free, 12046524k cached
Also: von 16 GB nutzt die Kiste nur 12,9 GB. Zum Cachen wäre also noch genug da.
Okayyy....
Hat dein Controller eine BBO? Das hilft enorm.
# /opt/AMCC/CLI/tw_cli //08071000-vmhost3> show Ctl Model (V)Ports Drives Units NotOpt RRate VRate BBU ------------------------------------------------------------------------ c2 9650SE-8LPML 8 6 2 0 1 1 OK
...oops, NotOpt = 1. Das war gestern noch anders...
Hier ein System von mir zum Vergleich: # tw_cli /c4 show Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-5 OK - - 64K 2793.93 ON OFF Port Status Unit Size Blocks Serial --------------------------------------------------------------- p0 OK u0 698.63 GB 1465149168 9QK12N02 p1 OK u0 698.63 GB 1465149168 9QK12N45 p2 OK u0 698.63 GB 1465149168 9QK12MZ5 p3 OK u0 698.63 GB 1465149168 9QK12N0M p4 OK u0 698.63 GB 1465149168 9QK12MWE p5 NOT-PRESENT - - - - p6 NOT-PRESENT - - - - p7 NOT-PRESENT - - - - Name OnlineState BBUReady Status Volt Temp Hours LastCapTest --------------------------------------------------------------------------- bbu On Yes OK OK OK 0 xx-xxx-xxxx
Ich habe hier eine Windows 2003 Maschine mit einem 3Ware 9650, auf dem habe ich 8 Festplatten als RAID 10 angelegt, damit die IO-Vorgänge ohne die Stripe-Berechnungen ablaufen.
Bonnie brachte dafür etwa 80-120 MB/s Schreibgeschwindigkeit und über 300 MB/s Lesegeschwindigkeit.
OK: # bonnie Bonnie 1.4: File './Bonnie.2840', size: 104857600, volumes: 1 Writing with putc()... done: 22452 kB/s 35.2 %CPU Rewriting... done: 24414 kB/s 3.1 %CPU Writing intelligently... done: 25065 kB/s 2.4 %CPU Reading with getc()... done: 54403 kB/s 100.1 %CPU Reading intelligently... done: 2148462 kB/s 100.7 %CPU Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 080710 1* 100 22452 35.2 25065 2.4 24414 3.1 54403 1002148462 101 113227.8 170
Das sieht nicht so berühmt aus, hier zum Vergleich das obige System (Quadcore 2,83GHz, 8 GB RAM): # bonnie -s 10000 -d /var Bonnie 1.4: File '/var/Bonnie.7549', size: 10485760000, volumes: 1 Writing with putc()... done: 75768 kB/s 88.7 %CPU Rewriting... done: 35933 kB/s 4.7 %CPU Writing intelligently... done: 90465 kB/s 16.2 %CPU Reading with getc()... done: 70661 kB/s 77.8 %CPU Reading intelligently... done: 383039 kB/s 22.8 %CPU Da müsste es noch Einstellungen geben, um die Leistung zu verbessern. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Sandy Drobic, Dienstag, 14. Oktober 2008 13:59:
Das sieht nicht so berühmt aus,
In der Tat. Deswegen meine ich ja, daß es am Storage mangelt...
Da müsste es noch Einstellungen geben, um die Leistung zu verbessern.
Tja, bloß wo setze ich an? -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann wrote:
Sandy Drobic, Dienstag, 14. Oktober 2008 13:59:
Das sieht nicht so berühmt aus,
In der Tat. Deswegen meine ich ja, daß es am Storage mangelt...
Da müsste es noch Einstellungen geben, um die Leistung zu verbessern.
Tja, bloß wo setze ich an?
Erinnere ich mich richtig, dass du zwei RAID5 auf dem Controller hast? Ich versuche immer, bei kleineren RAIDs so viele Platten wie möglich in eine Gruppe zu nehmen, damit die IO-Last auf möglichst viele Platten gleichzeitig schreiben kann. Bei meiner vorigen Mail standen auch die Cache-Einstellungen meines Controllers, wie sieht es bei dir damit aus? -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Sandy Drobic, Dienstag, 14. Oktober 2008 14:37:
Erinnere ich mich richtig, dass du zwei RAID5 auf dem Controller hast? Ich versuche immer, bei kleineren RAIDs so viele Platten wie möglich in eine Gruppe zu nehmen, damit die IO-Last auf möglichst viele Platten gleichzeitig schreiben kann.
Nein, es ist ein RAID-6-Verbund mit 6 Platten, eine Hotspare.
Bei meiner vorigen Mail standen auch die Cache-Einstellungen meines Controllers, wie sieht es bei dir damit aus?
Also der Cache ist eingeschaltet, wenn ich das richtig sehe. //08071000-vmhost3/c2/u0> show /all /c2/u0 status = OK /c2/u0 is not rebuilding, its current state is OK /c2/u0 is not verifying, its current state is OK /c2/u0 is initialized. /c2/u0 Cache State = on /c2/u0 volume(s) = 1 /c2/u0 name = Vol1 /c2/u0 serial number = 6RY821HE71D5A30040E6 /c2/u0 Ignore ECC policy = off /c2/u0 Auto Verify Policy = off /c2/u0 Storsave Policy = balance /c2/u0 Command Queuing Policy = on /c2/u0 Parity Number = 2 Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB) ------------------------------------------------------------------------ u0 RAID-6 OK - - - 64K 698.461 u0-0 DISK OK - - p4 - 232.82 u0-1 DISK OK - - p3 - 232.82 u0-2 DISK OK - - p2 - 232.82 u0-3 DISK OK - - p1 - 232.82 u0-4 DISK OK - - p0 - 232.82 u0/v0 Volume - - - - - 698.461 -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann wrote:
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB) ------------------------------------------------------------------------ u0 RAID-6 OK - - - 64K 698.461 u0-0 DISK OK - - p4 - 232.82 u0-1 DISK OK - - p3 - 232.82 u0-2 DISK OK - - p2 - 232.82 u0-3 DISK OK - - p1 - 232.82 u0-4 DISK OK - - p0 - 232.82 u0/v0 Volume - - - - - 698.461
Okay, bei RAID6 hast du mit 5 Platten nur die Nutzkapazität von drei Platten, das ist dann natürlich ein Unterschied zu meinen 5 Platten, die im RAID5 laufen. Da habe ich allein schon 4 effektive Platten. Aber selbst das ist noch keine Erklärung für die derart miserable Schreibperformance. Da vermute ich wirklich eine überlastete RAID6-CPU auf dem Controller. Ich weiss nicht, ob ein Downgrade-Möglichkeit von RAID6 nach RAID5 bei dem Controller möglich ist. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Okay, bei RAID6 hast du mit 5 Platten nur die Nutzkapazität von drei Platten, das ist dann natürlich ein Unterschied zu meinen 5 Platten, die im RAID5 laufen. Da habe ich allein schon 4 effektive Platten.
In meinem Fall war die Kapazität nicht so wichtig, weil es sowieso vorn und hinten reicht. Es ging mir mehr um Sicherheit. Ich wollte bei Ausfall einer Platte nicht schon nackt dastehen, denn auf dieser Maschine läuft die ultimative Brot&Butter-Applikation...
Aber selbst das ist noch keine Erklärung für die derart miserable Schreibperformance. Da vermute ich wirklich eine überlastete RAID6-CPU auf dem Controller.
Ich weiss nicht, ob ein Downgrade-Möglichkeit von RAID6 nach RAID5 bei dem Controller möglich ist.
OK, Du siehst es also auch so, daß das träge RAID6 die Ursache sein könnte. Ich werde mal sehen, ob ich so ein Downgrad hinkriege. -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann wrote:
Okay, bei RAID6 hast du mit 5 Platten nur die Nutzkapazität von drei Platten, das ist dann natürlich ein Unterschied zu meinen 5 Platten, die im RAID5 laufen. Da habe ich allein schon 4 effektive Platten.
In meinem Fall war die Kapazität nicht so wichtig, weil es sowieso vorn und hinten reicht. Es ging mir mehr um Sicherheit. Ich wollte bei Ausfall einer Platte nicht schon nackt dastehen, denn auf dieser Maschine läuft die ultimative Brot&Butter-Applikation...
Das ist natürlich ein Argument für möglichst hohe Sicherheit. Vielleicht ist es ja auch möglich, diese Applikation mehrfach redundant zu halten? Wir haben auch eine Applikation auf Oracle-Basis, und haben unseren Software-Hersteller getrieben, die Applikation RAC-tauglich zu machen, damit wir einen Cluster einsetzen können.
Aber selbst das ist noch keine Erklärung für die derart miserable Schreibperformance. Da vermute ich wirklich eine überlastete RAID6-CPU auf dem Controller.
Ich weiss nicht, ob ein Downgrade-Möglichkeit von RAID6 nach RAID5 bei dem Controller möglich ist.
OK, Du siehst es also auch so, daß das träge RAID6 die Ursache sein könnte. Ich werde mal sehen, ob ich so ein Downgrad hinkriege.
Das ist zumindest im Augenblick sehr wahrscheinlich. RAID6 ist ziemlich rechenintensiv. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Tue, 14 Oct 2008 15:52:39 +0200 Sandy Drobic <suse-linux@japantest.homelinux.com> wrote:
Aber selbst das ist noch keine Erklärung für die derart miserable Schreibperformance. Da vermute ich wirklich eine überlastete RAID6-CPU auf dem Controller.
Klingt plausibel, aber was erklärt die schlechte read-performance? -- Gruß, Tobias. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Tobias Crefeld wrote:
On Tue, 14 Oct 2008 15:52:39 +0200 Sandy Drobic <suse-linux@japantest.homelinux.com> wrote:
Aber selbst das ist noch keine Erklärung für die derart miserable Schreibperformance. Da vermute ich wirklich eine überlastete RAID6-CPU auf dem Controller.
Klingt plausibel, aber was erklärt die schlechte read-performance?
So schlecht war die Read-Performance ja nicht (immerhin über 200 MB/s). Interessant zu wissen wäre noch, ob die Messung im komplett unbelasteten System geschah (wie bei mir) oder mit einer laufenden Applikation, die selbst IO beansprucht hat während des Tests. Das würde eine Menge erklären. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Fri, 17 Oct 2008 10:45:59 +0200 Sandy Drobic <suse-linux@japantest.homelinux.com> wrote:
Tobias Crefeld wrote:
On Tue, 14 Oct 2008 15:52:39 +0200 Sandy Drobic <suse-linux@japantest.homelinux.com> wrote:
Aber selbst das ist noch keine Erklärung für die derart miserable Schreibperformance. Da vermute ich wirklich eine überlastete RAID6-CPU auf dem Controller.
Klingt plausibel, aber was erklärt die schlechte read-performance?
So schlecht war die Read-Performance ja nicht (immerhin über 200 MB/s).
Pardon, ich hätte "schlechtere" schreiben sollen. Ich meine damit nicht die bonnie-"Messwerte", sondern jene Feststellung: (Zitat)"Davon abgesehen kann diese Maschine auch viel schneller lesen. Mache ich ein dd if=/dev/sda of=/dev/null, und schaue dann mit vmstat 2 zu, dann ist die Zahl der Blocks in um ca. den Faktor 2-3 höher als bei der 'Problemmaschine'."(Zitatende) Nachdem in den meisten Umgebungen hauptsächlich gelesen wird, wirkt sich ein Engpass beim Lesen auch merklich stärker aus als mangelhafte Schreibperformance.
Interessant zu wissen wäre noch, ob die Messung im komplett unbelasteten System geschah (wie bei mir) oder mit einer laufenden Applikation, die selbst IO beansprucht hat während des Tests. Das würde eine Menge erklären.
Das würde dann allerdings unter "wer misst, misst Mist" laufen. -- Gruß, Tobias. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Tobias Crefeld wrote:
Interessant zu wissen wäre noch, ob die Messung im komplett unbelasteten System geschah (wie bei mir) oder mit einer laufenden Applikation, die selbst IO beansprucht hat während des Tests. Das würde eine Menge erklären.
Das würde dann allerdings unter "wer misst, misst Mist" laufen.
Ich nehme immer erst die wahrscheinlichere Annahme an als esoterische Möglichkeiten zu prüfen. (^-^) -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Tue, 14 Oct 2008 10:33:55 +0200 Sandy Drobic <suse-linux@japantest.homelinux.com> wrote:
Cachen ist das wirksamste, was man machen kann. In deinem Fall nutzt das OS den RAM als Cache für das Dateisystem, solange noch RAM frei ist, danach bricht die Performance zusammen, und du siehst das als Stehenbleiben der VMs.
Angeblich stellt er auch beim dump VOM RAID Unterschiede fest. Da hilft Cache nicht wirklich. Beim Schreiben wär es was anderes - zumindest mit write-back cache.
Hat dein Controller eine BBO? Das hilft enorm.
Was ist das? -- Gruß, Tobias. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Tobias Crefeld wrote:
On Tue, 14 Oct 2008 10:33:55 +0200 Sandy Drobic <suse-linux@japantest.homelinux.com> wrote:
Cachen ist das wirksamste, was man machen kann. In deinem Fall nutzt das OS den RAM als Cache für das Dateisystem, solange noch RAM frei ist, danach bricht die Performance zusammen, und du siehst das als Stehenbleiben der VMs.
Angeblich stellt er auch beim dump VOM RAID Unterschiede fest. Da hilft Cache nicht wirklich. Beim Schreiben wär es was anderes - zumindest mit write-back cache.
Hat dein Controller eine BBO? Das hilft enorm.
Was ist das?
Batterie Backup Option, eben genau die Batteriepufferung, damit der Controller write-back an Stelle von write-through verwendet. In meiner anderen Mail hatte ich das bonnie-Ergebnis gepostet, da ist mein System etwa drei mal so schnell in der Schreibleistung. Da scheint etwas noch nicht optimal zu laufen. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann schrieb:
Axel Birndt, Dienstag, 14. Oktober 2008 08:52:
Bevor Du da was umbaust, solltest Du eine konkrete Performanceanalyse zu dem Thema und Deiner praktischen Anwendung machen!
Dagegen stocken die Anwendungen (v.a. vmware-Maschinen) immer wieder, und das immer dann, wenn grad Last auf die Platten kommt. ... Sind denn die Lastprofile beider Maschinen gleich? IIRC sind das ca. 6000 Blocks bei Aufruf von "vmstat 2". Sobald die Last wieder absinkt, läuft die Maschine wieder flüssig. ... warum einfach der Befehl "vmstat 2" Deine Maschine in die Lastgrenze
... treibt ist mir nicht klar...
Demgegenüber habe ich eine ganz ähnliche Maschine daneben stehen (AMD statt Intel), auch mit 6 Platten, aber RAID5. Und hier kriege ich 25000 Blocks weggeschrieben. Diese Maschine kommt auch viel seltener ins Stocken. ... Bist Du Dir sicher das es wirklich am Raid-Level liegt? Klar bei Raid 6 müssen vom Controller 2x die Paritätsinformationen berechnet werden. Das sollte sich sicherlich beim Schreibvorgang auswirken, aber beim Lesen?
Davon abgesehen kann diese Maschine auch viel schneller lesen. Mache ich ein dd if=/dev/sda of=/dev/null, und schaue dann mit vmstat 2 zu, dann ist die Zahl der Blocks in um ca. den Faktor 2-3 höher als bei der "Problemmaschine". ...siehe oben.
Bist Du Dir sicher das wirklich der Raid-Level dafür verantwortlich ist? Wieviel VM's laufen denn pro Maschine bei Dir ? Haben die VM's ähnliche Lastprofile (sprich gleiche Last vom Benutzer und gleiche Aufgaben)? Sonst kannst Du das nicht vergleichen. Das ist jetzt zwar blöd, aber wirklich vergleichen kannst Du die Raid-Level nur, wenn Du unter gleichen Bedingungen die verschiedenen Raid-Level testest. Mangels Erfahrung kann ich Dir schlecht raten was Du ansonsten noch besser machen kannst. Gruß Axel -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Axel Birndt, Dienstag, 14. Oktober 2008 10:38:
Dagegen stocken die Anwendungen (v.a. vmware-Maschinen) immer wieder, und das immer dann, wenn grad Last auf die Platten kommt.
... Sind denn die Lastprofile beider Maschinen gleich?
So einigermaßen, ja. Auf beiden eine vm mit dns, dhcp, solches Zeugs, eine weitere vm beschäftigt sich mit Mails; und auf einer dritten läuft eine Datenbank, die ab und zu mal einiges wegschreibt, aber sonst auch nicht übermäßig IO erzeugt.
warum einfach der Befehl "vmstat 2" Deine Maschine in die Lastgrenze treibt ist mir nicht klar...
Nein, mit vmstat gucke ich zu, was passiert, während die Maschine Last hat.
... Bist Du Dir sicher das es wirklich am Raid-Level liegt? Klar bei Raid 6 müssen vom Controller 2x die Paritätsinformationen berechnet werden. Das sollte sich sicherlich beim Schreibvorgang auswirken, aber beim Lesen?
Also die Datenbankapplikation schreibt eben immer wieder einiges weg. Das kann ich am Statusfenster der Datenbank sehen. Tja, und dann ist es so, daß wenn ich zB in einer weiteren vm Windows XP installieren will, dann zieht das die Kiste leistungsmäßig so nach unten, daß sie fast unbenutzbar wird. Die LEDs an den sechs Platten leuchten minutenlang fast dauerhaft. Da denke ich eben, daß da was nicht stimmt.
Bist Du Dir sicher das wirklich der Raid-Level dafür verantwortlich ist? Wieviel VM's laufen denn pro Maschine bei Dir ? Haben die VM's ähnliche Lastprofile (sprich gleiche Last vom Benutzer und gleiche Aufgaben)? Sonst kannst Du das nicht vergleichen.
Mir ist schon klar, daß für eine endgültige Aussage die Maschinen genau gleiche Lastprofile haben müßten. Diesen Zustand kriege ich aber nicht her. Was ich dagegen beobachten kann ist, daß die eine Maschine immer wieder mal sehr stark einbricht, während die andere vielleicht etwas zäher läuft, ansonsten aber noch brauchbar weitermacht. Und bei der einen werkeln die Platten eben wie wild, bei der anderen ist das nicht so. -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann wrote:
Tja, und dann ist es so, daß wenn ich zB in einer weiteren vm Windows XP installieren will, dann zieht das die Kiste leistungsmäßig so nach unten, daß sie fast unbenutzbar wird. Die LEDs an den sechs Platten leuchten minutenlang fast dauerhaft. Da denke ich eben, daß da was nicht stimmt.
Das ist für mich eigentlich immer ein Zeichen dafür, dass eben nicht intelligent gecached wird, sondern stur direkt auf die Platten geschriebne wird. Wenn gecached wird, geht das in Schüben von sich, und die Daten können optimiert geordnet auf die Platten geschrieben werden. Wie sieht es mit der Belegung der Platten aus, ist da noch viel Luft auf den Platten, oder ist es schon ziemlich voll? Welches Dateisystem? -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Sandy Drobic, Dienstag, 14. Oktober 2008 14:02:
Wie sieht es mit der Belegung der Platten aus, ist da noch viel Luft auf den Platten, oder ist es schon ziemlich voll?
Im wesentlichen: /dev/sda2 xfs 20G 3,8G 17G 19% / /dev/sda5 xfs 150G 41G 110G 27% /var/lib/vmware
Welches Dateisystem?
Siehst Du oben - XFS. Nehm ich seit längerer Zeit ausschließlich, und habe damit noch keine nennenswerten Performance-Probleme erlebt. Eher im Gegenteil. -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann wrote:
Sandy Drobic, Dienstag, 14. Oktober 2008 14:02:
Wie sieht es mit der Belegung der Platten aus, ist da noch viel Luft auf den Platten, oder ist es schon ziemlich voll?
Im wesentlichen: /dev/sda2 xfs 20G 3,8G 17G 19% / /dev/sda5 xfs 150G 41G 110G 27% /var/lib/vmware
Was für Platten sind das, neuere SATA oder SAS? -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Sandy Drobic, Dienstag, 14. Oktober 2008 14:35:
Was für Platten sind das, neuere SATA oder SAS?
SATA, vielleicht vier Monate alt. -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann schrieb:
Und wenn IO-Last kommt, dann sehe ich in vmstat, daß die Zahl der Blocks out hochspringt, und für einige lange Sekunden bei diesem Maximalwert verbleibt. IIRC sind das ca. 6000 Blocks bei Aufruf von "vmstat 2". Sobald die Last wieder absinkt, läuft die Maschine wieder flüssig.
Auf meinen deutlich schwächeren Systemen kommt es nur zu Rucklern wenn Kollegen aus der Entwicklung in einem virtuellen System enormen I/O verursachen. das ist dann aber auf Hardwareebene eh nicht mehr zu kompensieren sondern muß berichtigt werden. Es gibt natürlich Anwendungen die ggf. per definition für VMware weniger geeignet sind. Ich denke da zum Beispiel an Hochleistungmailserver Alle Hinweise immer unter der Voraussetzung das VMware Host und Gäste ordentlich konfiguriert sind. -- i.A. Ralf Prengel Customer Care Manager Comline AG Hauert 8 D-44227 Dortmund/Germany Fon +49231 97575- 904 Fax +49231 97575- 905 EMail ralf.prengel@comline.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Ralf Prengel, Dienstag, 14. Oktober 2008 11:01:
Auf meinen deutlich schwächeren Systemen kommt es nur zu Rucklern wenn Kollegen aus der Entwicklung in einem virtuellen System enormen I/O verursachen. das ist dann aber auf Hardwareebene eh nicht mehr zu kompensieren sondern muß berichtigt werden.
Welcher Host? Welcher Gast?
Alle Hinweise immer unter der Voraussetzung das VMware Host und Gäste ordentlich konfiguriert sind.
Sagen wir es so: meine beiden Maschinen sind entweder gleich gut oder gleich schlecht konfiguriert. Welche Tuningmöglichkeiten hat man denn da bei vmware server? Als Host wie gesagt bei mir eine 11.0. -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann schrieb:
Ralf Prengel, Dienstag, 14. Oktober 2008 11:01:
Auf meinen deutlich schwächeren Systemen kommt es nur zu Rucklern wenn Kollegen aus der Entwicklung in einem virtuellen System enormen I/O verursachen. das ist dann aber auf Hardwareebene eh nicht mehr zu kompensieren sondern muß berichtigt werden.
Welcher Host? Welcher Gast?
Siemens Primergys (TX220er) als Hardware mit Raid 5. Suse 10.2 als Host migriere ich gerade zu 11.0 da 10.2 abgekündigt ist.
Alle Hinweise immer unter der Voraussetzung das VMware Host und Gäste ordentlich konfiguriert sind.
Sagen wir es so: meine beiden Maschinen sind entweder gleich gut oder gleich schlecht konfiguriert.
Welche Tuningmöglichkeiten hat man denn da bei vmware server? Als Host wie gesagt bei mir eine 11.0.
Aus meiner Sicht gibt es da wenig Optimierungsmöglichkeiten. Allen Systemen Ram fest zuteilen und das war es. Entweder die Hardware und das OS reichen out of the Box oder ich habe ein Problem. Optimierungen kosten Zeit und spätestens bei Updates bzw. neuer Harwdare fange ich wieder von vorne an zu schrauben. Wenn dann ein Host anfängt zu wackeln schiebe ich die eine oder mehrere VMwares auf einen anderen Host (offline per Virtual Center) bzw. bändigte mit dem Besitzer des virtuellen Systems den Unruhestifter. -- i.A. Ralf Prengel Customer Care Manager Comline AG Hauert 8 D-44227 Dortmund/Germany Fon +49231 97575- 904 Fax +49231 97575- 905 EMail ralf.prengel@comline.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Tue, 14 Oct 2008 10:03:28 +0200 Andre Tann <atann@gmx.net> wrote:
Und wenn IO-Last kommt, dann sehe ich in vmstat, daß die Zahl der Blocks out hochspringt, und für einige lange Sekunden bei diesem Maximalwert verbleibt. IIRC sind das ca. 6000 Blocks bei Aufruf von "vmstat 2". Sobald die Last wieder absinkt, läuft die Maschine wieder flüssig.
Demgegenüber habe ich eine ganz ähnliche Maschine daneben stehen (AMD statt Intel), auch mit 6 Platten, aber RAID5. Und hier kriege ich 25000 Blocks weggeschrieben. Diese Maschine kommt auch viel seltener ins Stocken. Davon abgesehen kann diese Maschine auch viel schneller lesen. Mache ich ein dd if=/dev/sda of=/dev/null, und schaue dann mit vmstat 2 zu, dann ist die Zahl der Blocks in um ca. den Faktor 2-3 höher als bei der "Problemmaschine".
Ich kann mir grad schlecht vorstellen, dass BEIM LESEN relevante Performance-Unterschiede zwischen RAID-5 und RAID-6 bestehen. Solange noch Redundanz besteht, haben beim Lesen irgendwelche XOR-Engines doch gar nichts zu tun. Als Überlegung: Besteht zwischen der Performance eines um eine Platte reduzierten RAID-6 und der eines RAID-5 überhaupt ein Unterschied? Zumindest für einen Test, ob RAID-6 die Ursache des Performance-Unterschieds zu Deinem anderen System ist, sollte das doch ausreichen. Ich würde die Ursache eher zwischen Host und RAID-Controller suchen. Sind das dieselben RAID-Controller mit derselben Ausstattung (RAM)? Gibt es Unterschiede in der Konfiguration, also IRQ-Belegung des Systems, verwendeter Steckplatz oder Einstellungen am RAID-Controller? Ansonsten sollte für einen Vergleich auch die Festplattenperformance vergleichbar sein. Reden wir eigentlich von VMware-Server oder von ESX? Falls Ersteres: In welcher Umgebung hattest Du die Testmessung gemacht - Guest oder Host? -- Gruß, Tobias. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Tobias Crefeld, Dienstag, 14. Oktober 2008 12:51:
Als Überlegung: Besteht zwischen der Performance eines um eine Platte reduzierten RAID-6 und der eines RAID-5 überhaupt ein Unterschied? Zumindest für einen Test, ob RAID-6 die Ursache des Performance-Unterschieds zu Deinem anderen System ist, sollte das doch ausreichen.
Du meinst also, einfach eine Platte rausziehen und schauen, ob es dadurch besser wird?
Ich würde die Ursache eher zwischen Host und RAID-Controller suchen. Sind das dieselben RAID-Controller mit derselben Ausstattung (RAM)? Gibt es Unterschiede in der Konfiguration, also IRQ-Belegung des Systems, verwendeter Steckplatz oder Einstellungen am RAID-Controller?
Das kann ich so nicht genau vergleichen, da das eine ein AMD, das andere ein Intel ist. Aber Speicher ist gleich, RAID-Controller ist gleich, Platten sind gleich.
Ansonsten sollte für einen Vergleich auch die Festplattenperformance vergleichbar sein.
Also bonnie hab ich jetzt mal laufen lassen, da schneidet mein RAID6 schon deutlich schlechter ab als das RAID5.
Reden wir eigentlich von VMware-Server oder von ESX? Falls Ersteres: In welcher Umgebung hattest Du die Testmessung gemacht - Guest oder Host?
Es ist ein vmware-Server. Und die Messungen habe ich im Host gemacht. Im Gast macht das doch kaum Sinn, oder? -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Tue, 14 Oct 2008 15:21:11 +0200 Andre Tann <atann@gmx.net> wrote:
Tobias Crefeld, Dienstag, 14. Oktober 2008 12:51:
Zumindest für einen Test, ob RAID-6 die Ursache des Performance-Unterschieds zu Deinem anderen System ist, sollte das doch ausreichen.
Du meinst also, einfach eine Platte rausziehen und schauen, ob es dadurch besser wird?
Ja, sicher. Kost' ja nix.
Ich würde die Ursache eher zwischen Host und RAID-Controller suchen. Sind das dieselben RAID-Controller mit derselben Ausstattung (RAM)? Gibt es Unterschiede in der Konfiguration, also IRQ-Belegung des Systems, verwendeter Steckplatz oder Einstellungen am RAID-Controller?
Das kann ich so nicht genau vergleichen, da das eine ein AMD, das andere ein Intel ist. Aber Speicher ist gleich, RAID-Controller ist gleich, Platten sind gleich.
Konfiguration und Firmware-Version zwischen den RAID-Controllern ist ebenfalls identisch (vom RAID-Level mal abgesehen)? AMD hat mit seinem Link-Konzept im Multiprozessorbetrieb gewisse Vorteile, weil nicht jede Prozesskommunikation über den Speicherbus laufen muss und diesen dadurch entlastet, aber sonst sollte das nichts ausmachen. Es sei denn, es gibt noch Unterschiede hinsichtlich 32 Bit vs. 64 Bit.
Es ist ein vmware-Server. Und die Messungen habe ich im Host gemacht. Im Gast macht das doch kaum Sinn, oder?
Naja, letztlich interessiert Dich ja vielleicht auch, wie schnell sich der Rechner aus Sicht der guest-OS "anfühlt". Z.B. bei ESX ist eine Messung ausschließlich im guest möglich. -- Gruß, Tobias. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (5)
-
Andre Tann -
Axel Birndt -
Ralf Prengel -
Sandy Drobic -
Tobias Crefeld