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

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 141698

Url: https://administrator.de/contentid/141698

Ausgedruckt am: 04.11.2024 um 18: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

Hallo,

verwende derzeit PRTG um die I/O's zu überwachen.
Unter 10:85 bzw 15:85 redest du von Verhältnis von Lese zu Schreibvorgang oder?

Gruss Marcel

Ja; 20:170 wären 10:85 was aber nicht den 100% entspricht, daher würde ich mehr Lese bevorzugen=>15:85 Random da eine DB bevorzugt quer durch die Prärie "hoppelt"

Hab die Werte gerundet deshalb bin ich wohl nicht auf die 100% gekommen

Hab nun mit DT-Performance eine Messung gemacht und bin auf folgende Werte gekommen:

Write Statistics:
Total records processed: 262144 @ 4096 bytes/record (4.000 Kbytes)
Total bytes transferred: 1073741824 (1048576.000 Kbytes, 1024.000 Mbytes)
Average transfer rates: 63456168 bytes/sec, 61968.914 Kbytes/sec
Number I/O's per second: 15492.229
Total passes completed: 0/1
Total errors detected: 0/1
Total elapsed time: 00m16.92s
Total system time: 00m02.56s
Total user time: 00m06.00s

Read Statistics:
Total records processed: 262144 @ 4096 bytes/record (4.000 Kbytes)
Total bytes transferred: 1073741824 (1048576.000 Kbytes, 1024.000 Mbytes)
Average transfer rates: 82297986 bytes/sec, 80369.127 Kbytes/sec
Number I/O's per second: 20092.282
Total passes completed: 1/1
Total errors detected: 0/1
Total elapsed time: 00m13.04s
Total system time: 00m01.39s
Total user time: 00m11.40s

Total Statistics:
Output device/file name: c:\dt.dat (device type=regular)
Type of I/O's performed: sequential (forward)
Data pattern read/written: 0x39c39c39
Total records processed: 524288 @ 4096 bytes/record (4.000 Kbytes)
Total bytes transferred: 2147483648 (2097152.000 Kbytes, 2048.000 Mbytes)
Average transfer rates: 71659225 bytes/sec, 69979.712 Kbytes/sec
Number I/O's per second: 17494.928
Total passes completed: 1/1
Total errors detected: 0/1
Total elapsed time: 00m29.96s
Total system time: 00m03.95s
Total user time: 00m17.40s
Starting time: Thu Apr 29 07:56:31 2010
Ending time: Thu Apr 29 07:57:01 2010

Können diese Werte stimmen?

Gruss Marcel

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

Hallo Sam,

danke für deine ausführliche Info!
Werde ich auf jeden Fall im Konzept beachten!

Gruss Marcel

Ich hätte noch eine letzte Frage, und zwar ist es normal, dass ich bei diesem Server so geringe I/O Zugriffe habe?
Höchsten Werte heute waren Schreiben: 1.180 und Lesen: 825

Die Datenbank ist etwa 10 GB gross und wird eigentlich laufend von unserem ERP System genutzt. Wir haben ca. 60 User die diese Datenbank mehr oder weniger intensiv nutzen.
Auch wird die Datenbank immer wieder mit der Datenbank des Hochregallagers abgeglichen und zudem läuft noch ein Loadbalancing der Hochregaldatenbank auf einen anderen Datenbankserver...

Mir kommt es nämlich fast so vor, als ob mir das Tool nur die I/O's der Partition C:\ überwacht...

Kennt jemand ein Tool, bei dem man die zu überwachende Partition angeben kann und welches die Daten über einen gewissen Zeitraum aufzeichnet... vielleicht auch grafisch

Danke!

Schöne Grüße
Marcel

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

Hallo Sam,

hab 34 GB RAM in diesem Server, also wäre es gut möglich dass es wirklich die realen Werte sind...
Wäre mir das Tool morgen mal anschauen!

Danke!

Gruss Marcel

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

Dass heißt dann aber, dass der SQL Server bzw. der Server einen grossteil der Datenbank im Speicher abbildet und dann nur wirklich relevante Lese- und Schreibvorgänge also zb. Neuanlage von Kunden und Aufträge auf die Platte schreibt.
Wenn dem so wäre, wie entscheidet der Server wieviel und was im Speicher abgebildet wird?

Gruss Marcel

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