Schreib-Lesezugriffe
Hallo zusammen,
ich habe einen Windows Server 2003 mit Microsoft SQL Server 2005 als Datenbankserver.
Dieser hat ein RAID 60 Verbund (2x 146 GB 10k SAS und 6 x 73 GB 15k SAS). Nun überwache ich derzeit die Schreib- /Lesezugriffe, da wir den Server demnächst möglicherweise virtualisieren und auf ein SAN legen wollen und ich deshalb gerne die I/O Zugriffe hätte.
Nun meine Frage, wieviel I/O Zugriffe pro Sekunde sollten die Platten schaffen bzw. was wäre ein kritischer Wert?
Ich habe derzeit einen Durchschnitt (berechnet aus Werten über 24 Stunden) von 20 Lese- und 170 Schreibzugriffen, obwohl es schon mal vorkommen kann, dass ich bei den Schreibzugriffen einen Wert von 1.000 bekomme, was aber natürlich nur für ein paar Sekunden anhält...
Kann mir vielleicht jemand sagen was meine Platten in dieser Konstellation schaffen sollten? Muss jetzt kein genauer Wert sein, mir würde es reichen wenn mir jemand sagen könnte, dass zb. 3.000 ohne Probleme möglich sein sollten bzw. ab wann es kritisch wird...
Besten Dank!
Schöne Grüße
Marcel
ich habe einen Windows Server 2003 mit Microsoft SQL Server 2005 als Datenbankserver.
Dieser hat ein RAID 60 Verbund (2x 146 GB 10k SAS und 6 x 73 GB 15k SAS). Nun überwache ich derzeit die Schreib- /Lesezugriffe, da wir den Server demnächst möglicherweise virtualisieren und auf ein SAN legen wollen und ich deshalb gerne die I/O Zugriffe hätte.
Nun meine Frage, wieviel I/O Zugriffe pro Sekunde sollten die Platten schaffen bzw. was wäre ein kritischer Wert?
Ich habe derzeit einen Durchschnitt (berechnet aus Werten über 24 Stunden) von 20 Lese- und 170 Schreibzugriffen, obwohl es schon mal vorkommen kann, dass ich bei den Schreibzugriffen einen Wert von 1.000 bekomme, was aber natürlich nur für ein paar Sekunden anhält...
Kann mir vielleicht jemand sagen was meine Platten in dieser Konstellation schaffen sollten? Muss jetzt kein genauer Wert sein, mir würde es reichen wenn mir jemand sagen könnte, dass zb. 3.000 ohne Probleme möglich sein sollten bzw. ab wann es kritisch wird...
Besten Dank!
Schöne Grüße
Marcel
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 141698
Url: https://administrator.de/contentid/141698
Ausgedruckt am: 22.11.2024 um 10:11 Uhr
13 Kommentare
Neuester Kommentar
Hi
nimm IOMeter und messe es selbst. Für DBs würde ich eine 80/20 Mischung Random nehmen als Mixtur. Du hast ja schon einen realwert: 10:85 , bzw 15:85 dann.
Das zeigt dir dein jetziges System an. Gute SANs (FC) leisten bei nur 10k EUR Aufwand auch schon bis 25k IOPS durch intelligentes Caching und verteilen der Daten (wird gleich verdoppelt wenn du volle redundante Anbindung+Controller haben willst)
Gruß
Sam
nimm IOMeter und messe es selbst. Für DBs würde ich eine 80/20 Mischung Random nehmen als Mixtur. Du hast ja schon einen realwert: 10:85 , bzw 15:85 dann.
Das zeigt dir dein jetziges System an. Gute SANs (FC) leisten bei nur 10k EUR Aufwand auch schon bis 25k IOPS durch intelligentes Caching und verteilen der Daten (wird gleich verdoppelt wenn du volle redundante Anbindung+Controller haben willst)
Gruß
Sam
Hi Marcel
es ist zwar ein künstlicher Test, aber für DB's ein akzeptabler Test. Je nach Größe der Datenblöcke (keine Ahnung welcher Datengrößen deine DB normal verarbeitet) weicht der Wert IOPS ab (höher bei kleinen Datenblöcken, dafür ist der Durchsatz stark minimiert, kleiner bei großen Blöcken dafür ist der Durchsatz beachtlich). Die von dir ermittelten Werte würde ich auf 20k IOPS hochskalieren. Aus meinem Umfeld/Angebot würde ich einen Infortrend G1840-4 mit 600GB SAS HDs (ich nutze die Ultrastar 15K600, 24/7) nehmen (damit sind etwa 45k IOPS möglich bei 16 Stück als R6 Array verschalten). Damit kannst du via SAN mit Redundanz zwei Server direkt anbinden. Da FC auch in VMs integrierbar ist, ist deine Zukunft damit auch möglich.
Gruß
Sam
es ist zwar ein künstlicher Test, aber für DB's ein akzeptabler Test. Je nach Größe der Datenblöcke (keine Ahnung welcher Datengrößen deine DB normal verarbeitet) weicht der Wert IOPS ab (höher bei kleinen Datenblöcken, dafür ist der Durchsatz stark minimiert, kleiner bei großen Blöcken dafür ist der Durchsatz beachtlich). Die von dir ermittelten Werte würde ich auf 20k IOPS hochskalieren. Aus meinem Umfeld/Angebot würde ich einen Infortrend G1840-4 mit 600GB SAS HDs (ich nutze die Ultrastar 15K600, 24/7) nehmen (damit sind etwa 45k IOPS möglich bei 16 Stück als R6 Array verschalten). Damit kannst du via SAN mit Redundanz zwei Server direkt anbinden. Da FC auch in VMs integrierbar ist, ist deine Zukunft damit auch möglich.
Gruß
Sam
Hi
ich kann mir schon vorstellen das dies die realen Zugriffe waren; sofern du genügend RAM drinnen hast und evtl lazywrite, kann es schon sein das der normale Filecache vom NTFS super dafür greift. Bei meinen Oracle 9.1 und DB2 7.4 sowie mySQL5 hilft der selten weiter so das ich recht viele IO's zu verzeichnen habe (mehrere hundert je s). Bei mir liefern die DBs selbst die beste Analyse mit (gerade bei mySQL) womit ich genau sehe wer wann wo getan hat und wo es optimiert werden kann.
Ein anderes Tool wäre von Hrn Withopf HDiskPerf.exe. Es zeigt auch die Latenzzeit und Blockgröße was oft ein sehr großer Faktor ist bei der Neuberechnung.
Gruß
Sam
ich kann mir schon vorstellen das dies die realen Zugriffe waren; sofern du genügend RAM drinnen hast und evtl lazywrite, kann es schon sein das der normale Filecache vom NTFS super dafür greift. Bei meinen Oracle 9.1 und DB2 7.4 sowie mySQL5 hilft der selten weiter so das ich recht viele IO's zu verzeichnen habe (mehrere hundert je s). Bei mir liefern die DBs selbst die beste Analyse mit (gerade bei mySQL) womit ich genau sehe wer wann wo getan hat und wo es optimiert werden kann.
Ein anderes Tool wäre von Hrn Withopf HDiskPerf.exe. Es zeigt auch die Latenzzeit und Blockgröße was oft ein sehr großer Faktor ist bei der Neuberechnung.
Gruß
Sam
Du kannst auch von O&O den CleverCache mal testen; der zeigt sehr (ehrlich) und detailiert die Cachehits an (welche er dann besser kann). Bei 34Gb und einem 64Bit OS sollte es wirklich möglich sein alles zu puffern. Ich habe eine 32GB (mit 144GB RAM) Ramdisk am laufen um ein cvs Repo; vorher dauerte ein auschecken etwa 5 Min mit einer 15k HD (R1), nun dauert es wenige Sekunden; das ist ein Zugewinn!
Gruß
Sam
Gruß
Sam
Hallo Marcel
afaik macht das die DB selbst, indem sie soviel RAM anzieht wie möglich um tables, schemas direkt in sich zu puffern. Der NT Cache hilft dann auch noch mit die Schreibzugriffe zu puffern; eine DB mit genug RAM kann schon einiges durchsetzen. Meine DBs liegen leider durch einen großen Anteil an Binärdateien immer im 100GB+ Bereich; da ist mit puffern schon das beste getan. Das Problem vom RAM ist dann auch noch das die Start/Stop Prozeduren enorm lange brauchen um sich komplett zu schreiben/lesen. Es gibt bei den meisten DBs ein Konfigfile/Tool in dem man sagen kann ob er das machen soll und wie viel er nutzen darf nicht das es zu Fällen von MemoryThrashing kommt.
Gruß
Sam
afaik macht das die DB selbst, indem sie soviel RAM anzieht wie möglich um tables, schemas direkt in sich zu puffern. Der NT Cache hilft dann auch noch mit die Schreibzugriffe zu puffern; eine DB mit genug RAM kann schon einiges durchsetzen. Meine DBs liegen leider durch einen großen Anteil an Binärdateien immer im 100GB+ Bereich; da ist mit puffern schon das beste getan. Das Problem vom RAM ist dann auch noch das die Start/Stop Prozeduren enorm lange brauchen um sich komplett zu schreiben/lesen. Es gibt bei den meisten DBs ein Konfigfile/Tool in dem man sagen kann ob er das machen soll und wie viel er nutzen darf nicht das es zu Fällen von MemoryThrashing kommt.
Gruß
Sam