On Freitag, 11. April 2008, Bernhard Geier wrote: > Probier mal folgende Mountoptionen bei den Clients: > rsize=8192.wsize=8192,timeo=14,intr Hab ich mal ergänzt. Mal sehen, ob das etwas bringt. Gefühlt noch nicht. > Ich vermute aber immer noch, dass die Platte ungünstig angesprochen wird > oder du den nfs-user-server statt des nfs-kernel-servers verwendest. Es ist zum Glück der nfs-kernel-server. > So sollte die hdparm-Ausgabe in etwa aussehen: > # hdparm /dev/hda > > /dev/hda: > multcount = 16 (on) > IO_support = 1 (32-bit) > unmaskirq = 1 (on) > using_dma = 1 (on) > keepsettings = 0 (off) > readonly = 0 (off) > readahead = 256 (on) > geometry = 19457/255/63, sectors = 312581808, start = 0 Standardmäßig sieht das bei mir so aus: /dev/hda: multcount = 0 (off) IO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 24321/255/63, sectors = 390721968, start = 0 Nachdem ich mich an deiner Ausgabe orientiert habe, habe ich mal folgenden Befehl abgesetzt: hdparm -u 1 -m 16 -c 1 -X /dev/hda Daraufhin läuft zum Glück noch alles. :) Normalerweise spiele ich mit hdparm nämlich sicherheitshalber nicht herum. Und meine Ausgabe sieht jetzt so aus: /dev/hda: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 24321/255/63, sectors = 390721968, start = 0 Dann habe ich bonnie++ noch mal laufen lassen und habe 35-45 MB/Sek gemessen. Eine deutliche Verbesserung in der Geschwindigkeit. Insgesamt geht bei Zugriffen die CPU jetzt nicht mehr über 1,5. Das ist schon mal fein. Ist das heutzutage (Mainboard ~2 Jahre alt) noch normal, dass man mit hdparm schrauben muss? Ich erinnere mich da höchstens noch an Woody, wo der DMA standardmäßig aus war. :) > Und nicht vergessen, den UDMA-Modus auszuwählen (hdparm -X ....) Mit -X kriege ich nur: setting xfermode to 0 (default PIO mode) Traue ich mich, einen anderen PIO-Mode von Hand zu setzen? Die Manpage macht mir Angst. > Wenn's dann immer noch nicht geht liegt's entweder am Netzwerk oder > irgendwo läuft ein Virenscanner. Virenscanner eher nicht (außer auf Anforderung vom AMaViS aus). Aber netzwerkseitig habe ich immer noch das Problem, dass ich beim Kopieren größerer Dateimengen immense Probleme mit NFS bekomme. Ich kopiere z.B. eine große Datei von der lokalen Platte auf ein NFS-gemountetes Verzeichnis. Parallel mache ich vom Client in meinem (NFS-) Home-Verzeichnis ein "find". Der gibt mir ca. 5 Dateien pro Sekunde aus. Auf dem Server hingegen geht ein "find" dafür rasend schnell und die Ausgabe fliegt nur noch an mir vorbei. Beim Kopieren über NFS habe ich ca. 11 MB/Sekunde. Das ist nett. Aber gleichzeitige Zugriffe über NFS sind wirklich quälend. Da die Server-Festplatte in jedem Fall schneller ist als 11 MB/Sekunde, könnte es natürlich das Netz sein. Könnte es denkbar sein, dass die IP-Queue bei großen NFS-Transfers vollläuft und deshalb "kleinere Anfragen" wie beim "find" (getattr oder sowas in der Richtung) einfach nicht zeitnah bearbeitet werden? Ich tippe da tatsächlich langsam eher auf esoterische NFS-Latenzen als auf Durchsatzprobleme. Gruß, Christoph -- When you do things right people won't be sure you've done anything at all.
Attachment:
signature.asc
Description: This is a digitally signed message part.