PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Unterschiedliche Schreibgeschwindigkeiten auf Plattendevice und Filesystem



MiGo
14.11.08, 11:03
Folgendes Problem:
Ich habe 2 HP Proliant DL160 G5 mit jeweils einer 250GB SATA-Platte, das System (SLES 10) läuft auf einem separaten Raid1. Der Controller ist ein LSI Logic / Symbios Logic SAS1064ET.

Die 250er Platten würde ich gerne per drbd zu einem gemeinsamen Storage koppeln, die Schreibleistung ist allerdings unbrauchbar.

Schreibe ich direkt auf das Festplattendevice bekomme ich einen Duchsatz von 15 MB/s (ziemlich peinlich für eine aktuelle Platte :)), mounte ich das Device allerdings und schreibe auf das Dateisystem ist der Durchsatz mit 150 MB/s vollkommen in Ordnung.

Weiß einer, warum sich die Geschwindigkeiten so unterschiedlich verhalten je nachdem ob man auf das Device direkt oder auf das eingehängte Device schreibt? Oder habe ich da schlicht irgend was nicht verstanden?

Infos zum System:

tokio1:/etc # cat SuSE-release
SUSE Linux Enterprise Server 10 (i586)
VERSION = 10
PATCHLEVEL = 2

tokio1:~ # uname -r
2.6.16.21-0.8-smp


tokio1:~ # lspci
00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 (rev 09)
00:1c.1 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 2 (rev 09)
00:1c.2 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 3 (rev 09)
00:1d.0 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 (rev 09)
00:1d.1 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 (rev 09)
00:1d.2 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 (rev 09)
00:1d.3 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #4 (rev 09)
00:1d.7 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller (rev 09)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9)
00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller (rev 09)
00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE Controller (rev 09)
00:1f.2 IDE interface: Intel Corporation 631xESB/632xESB/3100 Chipset SATA IDE Controller (rev 09)
02:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1) (rev 02)
03:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express
04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express
05:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port (rev 01)
05:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge (rev 01)
06:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 (rev 01)
09:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1064ET PCI-Express Fusion-MPT SAS (rev 08)

Und ein "Mitschnitt" des ganzen Unglücks:

tokio1:~ # dd if=/dev/zero of=/dev/sda=1GB count=1
1+0 records in
1+0 records out
1000000000 bytes (1.0 GB) copied, 25.109 seconds, 39.8 MB/s
tokio1:~ #

[sda1 angelegt]
tokio1:~ # dd if=/dev/zero of=/dev/sda1 bs=1GB count=1
1+0 records in
1+0 records out
1000000000 bytes (1.0 GB) copied, 72.8364 seconds, 13.7 MB/s
tokio1:~ #
[sda1 mit ext3 formatiert]

tokio1:~ # mount /dev/sda1 /mnt/
tokio1:~ # dd if=/dev/zero of=/mnt/hugefile bs=1GB count=1
1+0 records in
1+0 records out
1000000000 bytes (1.0 GB) copied, 6.89968 seconds, 145 MB/s

bla!zilla
14.11.08, 12:33
Weil ohne Dateisystem keine Caches genutzt werden und so ziemlich alles umgegangen wird.

MiGo
14.11.08, 14:46
Weil ohne Dateisystem keine Caches genutzt werden und so ziemlich alles umgegangen wird.
Daß der Schreibzugriff ohne Dateisystem langsamer ist kann ich nachvollziehen - allerdings ist ein Faktor 10 doch wohl ein wenig viel.
Insbesondere weil die drbd-Devices sich ebenfalls nur mit der Partitionsgeschwindigkeit syncronisieren (13.x MB/s), was kein normaler Wert sein kann - schon mein Desktoprechner bringt beim Schreiben direkt auf die Partition 50 MB/s und die Serverplatte sollte eher schneller als langsamer sein :)

just4uk
14.11.08, 18:26
Hi Migo,
habs mal getestet, Ergebniss:
[komplette Disk]
nas2:~# dd if=/dev/zero of=/dev/hdc bs=1GB count=1
1+0 Datensätze ein
1+0 Datensätze aus
1000000000 Bytes (1,0 GB) kopiert, 17,7013 Sekunden, 56,5 MB/s

[auf Part 1]
nas2:~# dd if=/dev/zero of=/dev/hdc1 bs=1GB count=1
1+0 Datensätze ein
1+0 Datensätze aus
1000000000 Bytes (1,0 GB) kopiert, 17,8413 Sekunden, 56,0 MB/s

[mit ext3 formatiert]
nas2:~# dd if=/dev/zero of=/mnt/hugefile bs=1GB count=1
1+0 Datensätze ein
1+0 Datensätze aus
1000000000 Bytes (1,0 GB) kopiert, 11,7751 Sekunden, 84,9 MB/s

[mit ext3 formatiert count=10]
nas2:~# dd if=/dev/zero of=/mnt/hugefile1 bs=1GB count=10
10+0 Datensätze ein
10+0 Datensätze aus
10000000000 Bytes (10 GB) kopiert, 174,654 Sekunden, 57,3 MB/s

Das Testsystem läuft auf einem Tyan Dual AMD Athlon MP Board (so runde 5 Jahre alt) und einer Maxtor 300GB SATA Disk.
Könnte es sein das die Hardware nicht so der bringer ist?

Gruß aus L.E.
Uwe

MiGo
15.11.08, 14:13
Könnte es sein das die Hardware nicht so der bringer ist?
Die Kiste ist ein HP Proliant DL 160 G5 - nicht gerade Selbstbastelhardware aus dem Arlt :)
Exakt deswegen frage ich hier ja nach - die Hardware sollte schon deutlich mehr Leistung bringen.

just4uk
15.11.08, 15:16
Ich kenne die ProLis wirklich zu genüge .....

Aber zum Thema.
Ich habe noch ein bisschen weiter gemacht, aber eigentlich aus dem Grund weil ich meine Platten stressen wollte da die eine oder andere in letzter Zeit öfters "end_request: I/O error, dev hdx, sector xxxx" brachte.

Fazit auf allen Platten hat sich der Speed nach einigen dd's bei rund 60MB/s "eingependelt" +/- wenn auf z.B. hda bzw. hda1 ohne FS geschrieben wird.
Mit FS pendelt sich das auf rund 90MB/s +/- ein.

Gruß aus L.E.
Uwe

P.S.: meine hdb ist wirklich im Eimer :mad:

Wene
15.11.08, 15:22
Kann es sein dass für diese Platten DMA nicht verwendet wird?

CoBra|Mike
15.11.08, 15:41
Kann es sein dass für diese Platten DMA nicht verwendet wird?

würde nicht erklären warum es mit Filesystem so viel besser geht...

Wene
15.11.08, 16:10
würde nicht erklären warum es mit Filesystem so viel besser geht...

Naja, doch. Bei nur einem GB kann es gut sein dass dieses vollständig im Cache landet bevor es geschrieben wird. Erst wenn Datenmengen geschrieben werden welche die Kapazität des Arbeitsspeichers um ein mehrfaches übersteigen werden die Ergebnisse vergleichbar. (Oder wenn Du einen Weg kennst, den Cache ab zu schalten.)

CoBra|Mike
15.11.08, 16:38
Naja, doch. Bei nur einem GB kann es gut sein dass dieses vollständig im Cache landet bevor es geschrieben wird. Erst wenn Datenmengen geschrieben werden welche die Kapazität des Arbeitsspeichers um ein mehrfaches übersteigen werden die Ergebnisse vergleichbar. (Oder wenn Du einen Weg kennst, den Cache ab zu schalten.)

da wäre eben mal ein Test mit ~10GB interessant, aber auch bei 1GB glaube ich nicht das sie besonders stark gecached werden.

In der Tat würden die erreichten 13,7MB/sec aber ziehmlich gut mit den 16,6MB/s von PIO4 zusammenpassen...was sagt denn `hdparm -I /dev/sdX`?

just4uk
15.11.08, 20:45
Ich vermute das bei 1GB nicht mehr viel mit chachen ist!
Das blöde, bei SATA, glaube ich das der DMA nicht geändert werden kann! Zumindest nicht mit hdparm, siehe:
nas1:~# hdparm -d 1 /dev/sda
/dev/sda:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Inappropriate ioctl for device

nas1:~# hdparm -d 1 /dev/sdb
/dev/sdb:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Inappropriate ioctl for device
nas1:~#

nas1:~# hdparm /dev/sdb
/dev/sdb:
IO_support = 0 (default 16-bit)
readonly = 0 (off)
readahead = 256 (on)
geometry = 38913/255/63, sectors = 625142448, start = 0
nas1:~#

Egal ob on oder off, das Ergebniss ist das selbe!

Gruß aus L.E.
Uwe

CoBra|Mike
15.11.08, 21:22
Ich vermute das bei 1GB nicht mehr viel mit chachen ist!
Das blöde, bei SATA, glaube ich das der DMA nicht geändert werden kann! Zumindest nicht mit hdparm, siehe:
nas1:~# hdparm -d 1 /dev/sda
/dev/sda:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Inappropriate ioctl for device

nas1:~# hdparm -d 1 /dev/sdb
/dev/sdb:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Inappropriate ioctl for device
nas1:~#

nas1:~# hdparm /dev/sdb
/dev/sdb:
IO_support = 0 (default 16-bit)
readonly = 0 (off)
readahead = 256 (on)
geometry = 38913/255/63, sectors = 625142448, start = 0
nas1:~#

Egal ob on oder off, das Ergebniss ist das selbe!

so weit ich das sehe sagt das doch alles nichts, mach doch einfach `hdparm -I /dev/sdb | grep dma`.
Und je nach Arbeitsspeicher wird er bei 1GB schon noch mehr oder weniger cachen, denke ich.

just4uk
15.11.08, 22:21
nas1:~# hdparm -I /dev/sdb|grep -A 2 -i dma
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
nas1:~#

Das DMA gesetzt ist war mir schon klar (zumindest bei meiner Disk) ich wollte nur zum Ausdruck bringen das dies bei SATA nicht (mit hdparm) geändert werden kann.

Gruß aus L.E.
Uwe

CoBra|Mike
15.11.08, 22:42
nas1:~# hdparm -I /dev/sdb|grep -A 2 -i dma
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
nas1:~#

Das DMA gesetzt ist war mir schon klar (zumindest bei meiner Disk) ich wollte nur zum Ausdruck bringen das dies bei SATA nicht (mit hdparm) geändert werden kann.


oh, o.k. na dann bin ich auch erstmal ratlos.

heatwalker
16.11.08, 11:23
.. hat sich erledigt.

Falsch gelesen