URL: https://www.overclockers.at/linux/software_raid_performance_im_keller_warum_170661/page_1 - zur Vollversion wechseln!
hiho,
erstmal meine verwendete hardware:
server:
asus p4pe
mobile pentium 4-m 2,2ghz
512mb ddr
2x promise tx133
1x wd 1,6gb (sys)
4x maxtor 120gb (raid-5)
2x excelstor 80gb (raid-1)
onboard broadcom gbit LAN
client:
2x xeon 2,66Ghz
asus pc-dl
intel CSA gbit LAN
folgendes szenario: hatte ursprünglich immer windows server 2003 als backupserver mit software raid-5 am laufen.
hab mir jetzt stattdessen ubuntu dapper auf die kiste geschmissen und dort mit mdadm ein softraid-5 angelegt. der build des arrays ist superschnell gegangen (im vergleich zu windows), von daher hab ich schonmal das beste vermutet in punkto performance.
also gut, nachdem das builden fertig war, hab ich (wiedermal) begonnen zu backuppen, und was muss ich da sehen: schreibzugriff auf das neu angelegte array is noch lahmer als unter windows.
linux softraid write: ca. 1,5-2mb/s
windows softraid write: ca. 6-7mb/s
linux softraid read: ca. 9-10mb/s
windows softraid read: ca. 25mb/s
- meine erste vermutung war jetzt: die platten laufen im PIO mode, dem ist aber nicht so (per hdparm nachgeschaut).
- zweite vermutung war: zu wenig ram, dem ist aber auch nicht so. ob jetzt 256, 512 oder 1024MB ram drinstecken ist auch egal --> läuft immer so grottig...
irgendwer software-raid benutzer unter linux?
wer hat eventuell einen tip für mich?
die erfahrung unter windows hat gezeigt das die kiste durchaus mehr kann als jetzt unter linux, bitte was is da los?
mfg
Zitat von Indigoirgendwer software-raid benutzer unter linux?
wer hat eventuell einen tip für mich?
was für raid level benutzt du?
auf der selben kiste läuft ein raid-1 am secondary ide channel (master-slave) mit zwei 80er platten, bei dem array stimmt die performance...
0, 1, 5 - alle gaenzlich ohne Probleme.
anzahl der platten im raid-5 array?
controller?
chunksize?
i was eh, i bin lästig - aber mich wurmts einfach im moment
Vier Platten (Seagate, 160GB 2MB Cache 7.2KRPM),
SIS740/961-onboard-IDE-Controller,
default
Leseperformance waren runde 50MB/s. (RAID5, Kernel 2.6.x<13, SSE-XOR fuer md, Athlon XP @ 550MHz)
was meinst du mit "SSE-XOR für md"
d.h. md kann SSE zur XOR berechnung "mißbrauchen"?
wie ist das zu aktivieren, bzw. ist es maybe per default on?
hmmm, jetzt wirds interessant:
hdparm wirft folgendes aus für das raid-5 array aus:
Code:indigo@server:~$ sudo hdparm -tT /dev/md1 /dev/md1: Timing cached reads: 1800 MB in 2.00 seconds = 900.00 MB/sec Timing buffered disk reads: 172 MB in 3.00 seconds = 57.33 MB/sec
Zitat von Indigowie kann ich unter linux das netzwerkinterface auf 100MBit/s drosseln? (zum testen)
Zitatmedia type
Set the physical port or medium type to be used by the device.
Not all devices can change this setting, and those that can vary in what values they support.
Typical values for type are 10base2 (thin Ethernet),
10baseT (twisted-pair 10Mbps Ethernet), AUI (external transceiver) and so on.
The special medium type of auto can be used to tell
the driver to auto-sense the media. Again, not all drivers can do this.
Zitat von Captionman ifconfig
OK, problem scheint lokalisiert:
die NIC ist das problem
broadcom GBit NIC --> performance 1-2mb/s
realtek 8139 100Mbit NIC --> wirespeed
realtek 8169 GBit NIC --> performance unter 1mb/s
aber warum? die cpu ist bei den GBit NICs nur am rumidlen, aber weitergehn tut auch nix, entweder hats bei den interupts was, aber kann ich mir auch nicht vorstellen, weil die beiden realtek NICs saßen im selben PCI slot - einmal gehts mit 10mb/s dahin und dann mit der gbit NIC geht garnixmehr weiter...
Gibt's irgendwelche besonders auffaelligen Ausbrecher in /proc/interrupts?
Welche Kernelversion verwendest du?
Hat dein Kernel MSI-Support aktiviert?
ausbrecher? du meinst mengenmäßig? ab wann ist es in deinen augen ein ausbrecher?
kernel ist 2.6.15-27
sorry, aber was ist MSI? und wie kann ich in erfahrung bringen ob das aktiviert ist?
ist halt alles noch mehr oder weniger neuland für mich...
Poste einfach mal das Listing von "/proc/interrupts".
MSI = Message-Signaled Interrupts, das sollte mit modernen PCI-Systemen ein performanteres Interrupt-Handling ermoeglichen. Ueber "zcat /proc/config.gz | fgrep -i msi" solltest du rausfinden koennen, ob die Option gesetzt wurde. Vielleicht taucht auch eine Info darueber im Debug-Ringbuffer (`dmesg`) auf... aber da bin ich mir jetzt nicht sicher (hab den Kernel hier nicht selbst gebaut).
/proc/interupts beherbergt im moment folgendes:
ich fahre aber im moment über die 100MBit realtek NIC (eth1)Code:CPU0 0: 334378 IO-APIC-edge timer 1: 613 IO-APIC-edge i8042 7: 0 IO-APIC-edge parport0 8: 3 IO-APIC-edge rtc 12: 96 IO-APIC-edge i8042 14: 6394 IO-APIC-edge ide0 15: 1761 IO-APIC-edge ide1 169: 18564574 IO-APIC-level acpi, ohci1394, eth1 177: 0 IO-APIC-level libata, ehci_hcd:usb4 185: 187960 IO-APIC-level ide2, ide3 193: 189555 IO-APIC-level ide4, ide5, uhci_hcd:usb3 201: 0 IO-APIC-level uhci_hcd:usb1 209: 0 IO-APIC-level uhci_hcd:usb2 217: 0 IO-APIC-level Intel 82801DB-ICH4 225: 2 IO-APIC-level eth0 NMI: 0 LOC: 334287 ERR: 0 MIS: 0
Dann liegt es allem Anschein nach wohl nicht am IRQ-Subsystem
overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2024