43292
10.11.2011
4805
14
0
Frische Linux Installation - Festplatten Performance
Hallo,
ich hoffe jemand kann mir weiterhelfen, da ich in Linux nicht soooo fit bin. Folgendes Szenario:
Es sind zwei 1000GB SATA Festplatten im System verbaut und am internen Dell SAS Controller angeschlossen. Im SETUP des Controllers habe ich die zwei Festplatten als IM (=Mirroring, RAID-1) eingerichtet. Die Gesamtkapazität ist also etwas knapp unter 1000GB. Wenn ich mit Win7 64-bit frisch installiere und mit ATTO Benchmark einen Schreib-/Lesezugriff durchführe, dann erreiche ich bis zu 135MB/sec Schreibgeschwindigkeit und Lesegeschwindigkeit knapp über 140MB/sec. Also mit der Leistung bin ich sehr zufrieden.
Ich habe nun auf dem System diverse Linux-Distris frisch installiert und ausprobiert, wie z.B. Ubuntu, Debian Lenny, Debian Squeeze, Fedora und auch Redhat. Wenn ich nun die Harddisk-Performance teste, dann komme ich auf ca. 110MB/sec. beim Lesen, und beim Schreiben nicht über 24MB/sec. Wieso ?!?
Was mache ich falsch bei Linux? Muss ich da irgendwelche bestimmten Treiber nachinstallieren oder warum funktioniert das nicht so wie es eigentlich tun sollte? Ich weiß ja, dass die Platten und der Controller in Ordnung sind und auch firmwaretechnisch auf dem aktuellsten Stand.
Bin für jeden erdenklichen Tip dankbar.
ich hoffe jemand kann mir weiterhelfen, da ich in Linux nicht soooo fit bin. Folgendes Szenario:
Es sind zwei 1000GB SATA Festplatten im System verbaut und am internen Dell SAS Controller angeschlossen. Im SETUP des Controllers habe ich die zwei Festplatten als IM (=Mirroring, RAID-1) eingerichtet. Die Gesamtkapazität ist also etwas knapp unter 1000GB. Wenn ich mit Win7 64-bit frisch installiere und mit ATTO Benchmark einen Schreib-/Lesezugriff durchführe, dann erreiche ich bis zu 135MB/sec Schreibgeschwindigkeit und Lesegeschwindigkeit knapp über 140MB/sec. Also mit der Leistung bin ich sehr zufrieden.
Ich habe nun auf dem System diverse Linux-Distris frisch installiert und ausprobiert, wie z.B. Ubuntu, Debian Lenny, Debian Squeeze, Fedora und auch Redhat. Wenn ich nun die Harddisk-Performance teste, dann komme ich auf ca. 110MB/sec. beim Lesen, und beim Schreiben nicht über 24MB/sec. Wieso ?!?
Was mache ich falsch bei Linux? Muss ich da irgendwelche bestimmten Treiber nachinstallieren oder warum funktioniert das nicht so wie es eigentlich tun sollte? Ich weiß ja, dass die Platten und der Controller in Ordnung sind und auch firmwaretechnisch auf dem aktuellsten Stand.
Bin für jeden erdenklichen Tip dankbar.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 176097
Url: https://administrator.de/forum/frische-linux-installation-festplatten-performance-176097.html
Ausgedruckt am: 21.04.2025 um 17:04 Uhr
14 Kommentare
Neuester Kommentar
Hi !
Kannst Du mir mal erklären, wie Du mit einem reinen Windows Benchmark-Tool unter Linux die Plattenperformance getestet hast? Mit Wine oder Virtualbox dazwischen?
mrtux
Kannst Du mir mal erklären, wie Du mit einem reinen Windows Benchmark-Tool unter Linux die Plattenperformance getestet hast? Mit Wine oder Virtualbox dazwischen?
mrtux
Hallo SloopGer
Naja, die Informationen die du uns gibst, sind recht spärlich.
Was für ein Controller ist das?
Hast du schon mal bei Google etwas geschaut, ob es für diesen Controller evt. "spezielle" Treiber für Linux gibt?
Vor allem ist die Frage, ob du hier nicht Birnen mit Äpfel vergleichst ... wenn du beispielsweise sehr grosse Dateien schreibst (z.B. eine 700MB-ISO-Datei), dann ist der reine Durchsatz natürlich viel höher, wie wenn du z.B. 1000 kleine 1KB-Dateien schreibst.
Daher lässt sich auch die Frage stellen, wie gut die beiden Benchmarks miteinander verglichen werden können.
LG
lousek
Naja, die Informationen die du uns gibst, sind recht spärlich.
Was für ein Controller ist das?
Hast du schon mal bei Google etwas geschaut, ob es für diesen Controller evt. "spezielle" Treiber für Linux gibt?
Vor allem ist die Frage, ob du hier nicht Birnen mit Äpfel vergleichst ... wenn du beispielsweise sehr grosse Dateien schreibst (z.B. eine 700MB-ISO-Datei), dann ist der reine Durchsatz natürlich viel höher, wie wenn du z.B. 1000 kleine 1KB-Dateien schreibst.
Daher lässt sich auch die Frage stellen, wie gut die beiden Benchmarks miteinander verglichen werden können.
LG
lousek
@mrtux: nichst dergleichen ;) ich habe vorher Win7 installiert, frische Installation. Danach mit ATTO Benchmark und CrystalDiskmark getestet und mir die Werte aufgeschrieben. Danach das System wieder platt gemacht, da ich komplett formatiert habe und Linux aufgesetzt habe. Also kein Hypervisor.
@Lousek: es ist ein Dell SAS Integrated Controller und auf support.dell.com gibts auch Treiber für RHEL 5. Ich habe jedoch RHEL 6 getestet gehabt. Der Treiber seitens Dell ist jedoch schon über 4 Jahre alt. Die haben das nicht so sehr mit der Aktualität
Die letzte Firmware von diesem Controller und meinem BIOS hatte ich bereits vor einer Woche upgedatet.
Äpfel mit Birnen Vergleich fand nicht statt. Ich kann ja im ATTO Benchmark verschiedene Modi wählen, und defaultmässig wird via direct i/o und overlapped i/o mit einer Queue-Tiefe von 4 getestet. Dabei fängt bei 0.5k an, geht auf 1k hoch, 2k, 4k, bis auf maximum 8192k. Jeder einzelne Test wird mit der entsprechenden Lese- und Schreibgeschwindigkeit angezeigt. Das ist ja ziemlich easy bei Windows gewesen.
Bei Linux habe ich diverse Tests gefahren.
(1) das etwas unaussagekräftige "hdparm -t /dev/blabla" mit dem man wenigstens einen Anhaltspunkt hat. Am besten man lässt das 3x laufen und bildet davon nen Mittelwert. Hier krieg ich 106-107 MB/sec als Leserate.
(2) dd if=/dev/zero of=/tmp/test.img bs=8k count=256k um die Lesegeschwindigkeit zu checken. Als Resultat erhalte ich 115 MB/s angezeigt.
dd if=/dev/zero of=test bs=1048576 count=2048 um die Schreibgeschwindigkeit zu checken. Hier erhalte ich 122 MB/s was aber nicht stimmen kann. Hier füge ich jetzt noch conv=fdatasync in das Kommando ein, um die WAHRE Schreibgeschwindigkeit zu checken. Das führt dann nämlich dazu, dass der Output erst beendet wird, nachdem die Daten auch wirklich auf dem physikalischen Datenträger geschrieben wurden. So kommt es nicht zu Verfälschungen des Resultates (!) Also setze ich den abgeänderten Befehl ab "dd if=/dev/zero of=test bs=1048576 count=2048 conv=fdatasync" und erhalte als Resultat schon gleich 74,8 MB/s was ich auch nicht so recht glauben kann
(3) und allerletzt das graphische Tool GUI unter System > Administration > Disk utility. Es zeigt mir eine hohe Leserate von über 120MB/sec an, aber eine Schreibrate von max. 25MB/sec.
Zur Sicherheit habe ich auch mal "iostat -d -x 5 3" abgesetzt und mir die Werte r/s, w/s, svctm (average service time) und Utilization in % angeguckt. Die Werte sehen alle gut aus, stehen alle auf 0 und zeigen mir also keinen Flaschenhals im Bus an.
Was nu? Irgendeine Idee?
@Lousek: es ist ein Dell SAS Integrated Controller und auf support.dell.com gibts auch Treiber für RHEL 5. Ich habe jedoch RHEL 6 getestet gehabt. Der Treiber seitens Dell ist jedoch schon über 4 Jahre alt. Die haben das nicht so sehr mit der Aktualität
Die letzte Firmware von diesem Controller und meinem BIOS hatte ich bereits vor einer Woche upgedatet.Äpfel mit Birnen Vergleich fand nicht statt. Ich kann ja im ATTO Benchmark verschiedene Modi wählen, und defaultmässig wird via direct i/o und overlapped i/o mit einer Queue-Tiefe von 4 getestet. Dabei fängt bei 0.5k an, geht auf 1k hoch, 2k, 4k, bis auf maximum 8192k. Jeder einzelne Test wird mit der entsprechenden Lese- und Schreibgeschwindigkeit angezeigt. Das ist ja ziemlich easy bei Windows gewesen.
Bei Linux habe ich diverse Tests gefahren.
(1) das etwas unaussagekräftige "hdparm -t /dev/blabla" mit dem man wenigstens einen Anhaltspunkt hat. Am besten man lässt das 3x laufen und bildet davon nen Mittelwert. Hier krieg ich 106-107 MB/sec als Leserate.
(2) dd if=/dev/zero of=/tmp/test.img bs=8k count=256k um die Lesegeschwindigkeit zu checken. Als Resultat erhalte ich 115 MB/s angezeigt.
dd if=/dev/zero of=test bs=1048576 count=2048 um die Schreibgeschwindigkeit zu checken. Hier erhalte ich 122 MB/s was aber nicht stimmen kann. Hier füge ich jetzt noch conv=fdatasync in das Kommando ein, um die WAHRE Schreibgeschwindigkeit zu checken. Das führt dann nämlich dazu, dass der Output erst beendet wird, nachdem die Daten auch wirklich auf dem physikalischen Datenträger geschrieben wurden. So kommt es nicht zu Verfälschungen des Resultates (!) Also setze ich den abgeänderten Befehl ab "dd if=/dev/zero of=test bs=1048576 count=2048 conv=fdatasync" und erhalte als Resultat schon gleich 74,8 MB/s was ich auch nicht so recht glauben kann
(3) und allerletzt das graphische Tool GUI unter System > Administration > Disk utility. Es zeigt mir eine hohe Leserate von über 120MB/sec an, aber eine Schreibrate von max. 25MB/sec.
Zur Sicherheit habe ich auch mal "iostat -d -x 5 3" abgesetzt und mir die Werte r/s, w/s, svctm (average service time) und Utilization in % angeguckt. Die Werte sehen alle gut aus, stehen alle auf 0 und zeigen mir also keinen Flaschenhals im Bus an.
Was nu? Irgendeine Idee?
Mach's Dir und uns nicht so schwer mit so vielen Benches. Nimm die Windowsinstallation und kopier ein paar Dateien hin und her (große ISOs z.B.) . Dann nimm Linux und mach es mit den selben Dateien und miss einfach die Zeit. Wenn es signifikante Unterschiede gibt, dann können wir immer noch weitermachen mit Benchmark xy.
Wenn Du magst, schließ noch eine weitere Platte an und kopier zusätzlich vom Raid auf diese und verwende auch mal einen Ordner mit 10000 Fitzeldateien. <- Edit: letzteren kann Dir das Windowstool fctest von xbitlabs erstellen.
Wenn Du magst, schließ noch eine weitere Platte an und kopier zusätzlich vom Raid auf diese und verwende auch mal einen Ordner mit 10000 Fitzeldateien. <- Edit: letzteren kann Dir das Windowstool fctest von xbitlabs erstellen.
Hatte ich doch schon gemacht als ich Win7 drauf hatte. Ich teste immer mit drei verschiedenen Dateien. Die haben die exakten Größe von 5MB, 500MB und 1000MB. Die verwende ich für Dateikopieroptionen. Das hatte mich ja dazu veranlasst zu benchmarken, um den Fehler zu finden. Bei Linux dauert's ewig, bei Win7 ging das alles ratzfatz. Ich brauch keine weitere Platte anschließen,wieso sollte ich noch mehr Faktoren ins Problem einbauen?Ich hab doch ein ganz klares Szenario und möchte durch FehlerAUSschlussverfahren dem Problem näher kommen und nicht dadurch, indem ich noch weitere Störfaktoren miteinbeziehe.
Hatte ich doch schon gemacht...
Entschuldige bitte, aber davon hattest Du bislang geschwiegen.
Hallo SloopGER,
und
und
falls der erste Befehl keine Ausgabe bringt, dann poste alternativ mal die Ausgabe ohne das grep-Kommando.
Damit wird dann zumindest klar, welche Treiber Du unter Linux genau verwendest.
Markus
Zitat von @43292:
Was mache ich falsch bei Linux? Muss ich da irgendwelche bestimmten Treiber nachinstallieren oder warum funktioniert das nicht so wie es eigentlich tun sollte?
Ich weiß ja, dass die Platten und der Controller in Ordnung sind und auch firmwaretechnisch
auf dem aktuellsten Stand.
poste mal bitte die Ausgabe vonWas mache ich falsch bei Linux? Muss ich da irgendwelche bestimmten Treiber nachinstallieren oder warum funktioniert das nicht so wie es eigentlich tun sollte?
Ich weiß ja, dass die Platten und der Controller in Ordnung sind und auch firmwaretechnisch
auf dem aktuellsten Stand.
lspci -k | grep -iA3 satauname -alsmod | sortDamit wird dann zumindest klar, welche Treiber Du unter Linux genau verwendest.
Markus
@DerWoWusste: DU hast dich nicht zu entschuldigen, sondern ICH Es stand wirklich nirgends dabei, konntest es daher auch nicht wissen. Sorry!
(weil die SATA-Platten am internen Dell SAS 5/i Controller hängen, nicht an den 'normalen' SATA-Ports auf dem Motherboard)
und dann noch
Es stand wirklich nirgends dabei, konntest es daher auch nicht wissen. Sorry!(weil die SATA-Platten am internen Dell SAS 5/i Controller hängen, nicht an den 'normalen' SATA-Ports auf dem Motherboard)
- lspci -k | grep -iA3 raid
05:0b.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS (rev 01)
Subsystem: Dell SAS 5/iR Integrated RAID Controller
Kernel driver in use: mptsas
Kernel modules: mptsas
Subsystem: Dell SAS 5/iR Integrated RAID Controller
Kernel driver in use: mptsas
Kernel modules: mptsas
- uname -a
Linux test01 2.6.32-71.el6.x86_64 #1 SMP Wed Sep 1 01:33:01 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
und dann noch
- root@test01:/# lsmod | sort
ahci 39105 0
ata_generic 3611 0
ata_piix 22588 1
autofs4 27683 3
cdrom 39769 1 sr_mod
crc_itu_t 1683 1 firewire_core
crc_t10dif 1507 1 sd_mod
dcdbas 9153 0
dm_log 10088 2 dm_mirror,dm_region_hash
dm_mirror 14003 0
dm_mod 76856 18 dm_mirror,dm_log
dm_region_hash 12200 1 dm_mirror
drm 200778 3 radeon,ttm,drm_kms_helper
drm_kms_helper 32113 1 radeon
edac_core 46055 3 i5000_edac
ext4 353979 5
firewire_core 50853 1 firewire_ohci
firewire_ohci 24867 0
freq_table 4847 1 p4_clockmod
hwmon 2464 1 i5k_amb
i2c_algo_bit 5664 1 radeon
i2c_core 31274 5 i2c_i801,radeon,drm_kms_helper,drm,i2c_algo_bit
i2c_i801 11190 0
i5000_edac 8833 0
i5k_amb 5039 0
ip6table_filter 2855 1
ip6_tables 19392 1 ip6table_filter
ip6t_REJECT 4562 2
ipt_REJECT 2349 0
ipv6 321209 40 ip6t_REJECT,nf_conntrack_ipv6
iTCO_vendor_support 3022 1 iTCO_wdt
iTCO_wdt 11708 0
jbd2 89033 1 ext4
mbcache 7918 1 ext4
mptbase 91106 2 mptsas,mptscsih
mptsas 51510 4
mptscsih 35302 1 mptsas
nf_conntrack 79643 2 nf_conntrack_ipv6,xt_state
nf_conntrack_ipv6 19655 4
nls_utf8 1389 1
p4_clockmod 20059 0
parport 37327 2 ppdev,parport_pc
parport_pc 22944 0
pata_acpi 3667 0
ppdev 8695 0
radeon 797054 1
scsi_transport_sas 35036 1 mptsas
sd_mod 37221 9
serio_raw 4816 0
sg 30186 0
shpchp 33448 0
speedstep_lib 5367 1 p4_clockmod
sr_mod 16162 0
sunrpc 241630 1
tg3 148918 0
ttm 46942 1 radeon
xt_state 1458 4
ata_generic 3611 0
ata_piix 22588 1
autofs4 27683 3
cdrom 39769 1 sr_mod
crc_itu_t 1683 1 firewire_core
crc_t10dif 1507 1 sd_mod
dcdbas 9153 0
dm_log 10088 2 dm_mirror,dm_region_hash
dm_mirror 14003 0
dm_mod 76856 18 dm_mirror,dm_log
dm_region_hash 12200 1 dm_mirror
drm 200778 3 radeon,ttm,drm_kms_helper
drm_kms_helper 32113 1 radeon
edac_core 46055 3 i5000_edac
ext4 353979 5
firewire_core 50853 1 firewire_ohci
firewire_ohci 24867 0
freq_table 4847 1 p4_clockmod
hwmon 2464 1 i5k_amb
i2c_algo_bit 5664 1 radeon
i2c_core 31274 5 i2c_i801,radeon,drm_kms_helper,drm,i2c_algo_bit
i2c_i801 11190 0
i5000_edac 8833 0
i5k_amb 5039 0
ip6table_filter 2855 1
ip6_tables 19392 1 ip6table_filter
ip6t_REJECT 4562 2
ipt_REJECT 2349 0
ipv6 321209 40 ip6t_REJECT,nf_conntrack_ipv6
iTCO_vendor_support 3022 1 iTCO_wdt
iTCO_wdt 11708 0
jbd2 89033 1 ext4
mbcache 7918 1 ext4
mptbase 91106 2 mptsas,mptscsih
mptsas 51510 4
mptscsih 35302 1 mptsas
nf_conntrack 79643 2 nf_conntrack_ipv6,xt_state
nf_conntrack_ipv6 19655 4
nls_utf8 1389 1
p4_clockmod 20059 0
parport 37327 2 ppdev,parport_pc
parport_pc 22944 0
pata_acpi 3667 0
ppdev 8695 0
radeon 797054 1
scsi_transport_sas 35036 1 mptsas
sd_mod 37221 9
serio_raw 4816 0
sg 30186 0
shpchp 33448 0
speedstep_lib 5367 1 p4_clockmod
sr_mod 16162 0
sunrpc 241630 1
tg3 148918 0
ttm 46942 1 radeon
xt_state 1458 4
Hallo,
also ich bin kein Experte für RedHat und weiß nicht, wie die ihre Kernel patchen. Aber ich würde mit solcher Hardware einen deutlich moderneren Kernel nehmen als 2.6.32. Ich meine wegen der Terybyte Platten.
Hast Du eine Ahnung, welche Versionen der anderen Linuxdistributionen Du ausprobiert hast? Vielleicht bootest Du mal eine Live-CD von einer sehr aktuellen Distribution und kopierst Deine Testdateien, so wie Du es oben beschrieben hast. Es wäre interessant zu sehen, ob's da Unterschiede gibt.
Markus
also ich bin kein Experte für RedHat und weiß nicht, wie die ihre Kernel patchen. Aber ich würde mit solcher Hardware einen deutlich moderneren Kernel nehmen als 2.6.32. Ich meine wegen der Terybyte Platten.
Hast Du eine Ahnung, welche Versionen der anderen Linuxdistributionen Du ausprobiert hast? Vielleicht bootest Du mal eine Live-CD von einer sehr aktuellen Distribution und kopierst Deine Testdateien, so wie Du es oben beschrieben hast. Es wäre interessant zu sehen, ob's da Unterschiede gibt.
Markus
wobei die eingesetzte Workstation von Dell ja auch nicht gerade aktuell ist ;) na gut, ich lade mir gerade Debian Squeeze LIVE CD herunter, dann teste ich damit mal.
Mir fällt noch ein, Linux braucht beim Kopieren gerne viel Arbeitsspeicher. Je mehr davon, um so schneller der Kopiervorgang. Wieviel Speicher hat denn Dein Rechner?
Markus
Markus
4 Gig ECC-RAM auf 667MHz mit 5-5-5 (11) im Quad-Channel-Mode
ich denke nicht, dass es daran liegt, da ich es ja -wie weiter oben irgendwo erläutert- mit "iostat -d -x 5 3" überwacht habe.
Zitat von @43292:
wobei die eingesetzte Workstation von Dell ja auch nicht gerade aktuell ist ;) na gut, ich lade mir gerade Debian Squeeze LIVE CD
herunter, dann teste ich damit mal.
wobei die eingesetzte Workstation von Dell ja auch nicht gerade aktuell ist ;) na gut, ich lade mir gerade Debian Squeeze LIVE CD
herunter, dann teste ich damit mal.
steht aber in krassem Widerspruch zu:
Zitat von @64748:
Hallo,
also ich bin kein Experte für RedHat und weiß nicht, wie die ihre Kernel patchen. Aber ich würde mit solcher
Hardware einen deutlich moderneren Kernel nehmen als 2.6.32. Ich meine wegen der Terybyte Platten.
Hallo,
also ich bin kein Experte für RedHat und weiß nicht, wie die ihre Kernel patchen. Aber ich würde mit solcher
Hardware einen deutlich moderneren Kernel nehmen als 2.6.32. Ich meine wegen der Terybyte Platten.
Da solltest Du dann vielleicht mal was Neueres von RedHat oder Ubuntu oder whatever nehmen...
Lonesome Walker
