Hohe CPU bei Festplattenzugriff

[PapaNissje]

Hallo!

Ich kämpfe hier mit einem dicken Problem und hoffe, dass ich hier Weißheit finde

Meine Konfiguration:
AMD Sempron 64 LE-1200
ASUS M2N68
2GB DDR2-800
Grafikkarte Gigabyte 256MB 8400GS Passiv PCIe
DVB-Karte TechnoTrend S-1401 Budget
SATA-Festplatte von Samsung

Kernel ist 2.6.25 (Distribution ist easyVDR, setzt auf Debian auf, welches weiß ich leider nicht genau, falls es wichtig wird, schaue ich nach).

Kurz und knapp:
Wenn meine Festplatte "arbeitet", das heißt einen Datentransfer macht, steigt die CPU-Auslastung auf 100%. Davon sind große Teile (meist >90%) Kernel-Zeit (Bild)!


dmesg gibt nichts her, hdparm -t sagt mir etwas von 75MB/s

Kann sich das jemand erklären?

Problematisch an der Sache ist, dass der Prozess, der die Platte benutzt ein Echtzeitprozess ist und mit nic -19 läuft. Somit zieht der alles runter. Verwaltet wird der Rechner per SSH. Das ist dann auch nicht mehr möglich

Viele Grüße
PapaNissje

[Danielx]

Hallo und willkommen im df.de!

Wenn meine Festplatte "arbeitet", das heißt einen Datentransfer macht, steigt die CPU-Auslastung auf 100%. Davon sind große Teile (meist >90%) Kernel-Zeit (Bild)!

Ist dies nur bei dem genannten Programm "vdr" der Fall oder bei jedem Festplattenzugriff bzw. Kopiervorgang, z.B. bei cp oder dd?

Gruß,
Daniel

[OppaErich]

Aha, ich dachte das sei normal. Das Problem habe ich ja auch dass Festplattenzugriffe die ganze Rechenzeit auffressen (s. SATA Performance thread). Die Ladezeiten wären mir ja ziemlich Schnuppe wenn denn wenigstens Maus & Tastatur reagieren würden. Bei mir ist es egal, Zugriff auf die Platte frisst mindestens einen Kern auf.

[PapaNissje]

Endlich versteht man mich

Die hohe Last habe ich bei allen Festplattenzugriffe. Mein Lieblingstest ist "dd if=/dev/zero of=testfile". Da dd nicht mit nice -19 läuft, reagiert alles noch normal. VDR muss jedoch soaggressiv laufen, RealTime.

@OppaErich
Es kann sein, dass unser Problem ähnlich ist. Bei mir reagiert alles, außer wenn der Prozeß, der die Last verursacht einen sehr niedrigen nice-Wert hat.

Ich habe gerade mal die TV-Karte ausgebaut -> keine Besserung
Ich habe die SATA Platte im Bios auf AHCI gestellt -> keine Besserung

Ich glaube, dass ein Kernelparameter Schuld hat (Vermutung eines Laien).

Gruß
Alex

[Spasswolf]

Kannst du die Ausgaben von

Code: Alles auswählen

dmesg
lspci -nn
hdparm -i /dev/<deinePlatte>

nach http://nopaste.debianforum.de/ stellen?

[PapaNissje]

Bitte schön: http://nopaste.debianforum.de/17963

Gruß
PapaNissje

[Lord_Carlos]

Ich hatte auch eine sehr hohe CPU zeit beim runterladen von Torrents mit über 1MB/sec. War am verzweifeln und kurz davor meine HDD umtauschen zu lassen. Wie sich herausgestellt hat lag es am JFS filesystem, mit ext3 läuft alles wie geschmiert.
Vielleicht hast du ja ein ähnliches Problem.

Mfg Lord-carlos

[OppaErich]

Endlich versteht man mich
...
Ich habe die SATA Platte im Bios auf AHCI gestellt -> keine Besserung
...

Aha, das könnte etwas bringen ? Im Bios habe ich noch gar nicht herumgespielt weil ich auch gar nicht weiß was sich hinter den ganzen Geschichten verbirgt. NVIDIA haben wir beide, MCP73 bei mir, MCP67 bei Dir und "CHS" der Platten sind identisch obwohl es verschiedene Platten sind. Bei Dir besteht ja noch Hoffnung, da war ja jede Menge 'unknown' in den Logs.

[Spasswolf]

Das "unknown" bei lspci hat keine funktionelle Bedeutung und kann mit

Code: Alles auswählen

update-pciids

behoben werden.

Hier könnte eventuell das Problem liegen, da kein DMA Modus als aktiv angezeigt wird:

Code: Alles auswählen

Model=ST3250820AS , FwRev=3.AAC , SerialNo= 4QE01264
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7

* signifies the current active mode

Das sollte eigentlich so aussehen:

Code: Alles auswählen

..
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
...

Ich würde als erstes einen neuen Kernel (2.6.28 oder zuerst 2.6.26 aus Lenny) ausprobieren.

[OppaErich]

Ich sag ja da gibts Hoffnung...

Code: Alles auswählen

oppa-1:/home/oppa# hdparm -iI /dev/sda

/dev/sda:

 Model=SAMSUNG HD252KJ                         , FwRev=CM100-12, SerialNo=S0NJJDQQ200206      
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
 BuffType=DualPortCache, BuffSize=16384kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=488397168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-3,4,5,6,7

 * signifies the current active mode

Capabilities:

	Recommended acoustic management value: 254, current value: 0
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 udma7 
	     Cycle time: min=120ns recommended=120ns

Commands/features:
	Enabled	Supported:
	   *	SMART feature set
	    	Security Mode feature set

	    	SET_MAX security extension
	    	Automatic Acoustic Management feature set

	    	DMA Setup Auto-Activate optimization

Die ganzen gesetzten Optionen habe ich mal rausgeschnibbelt damit das nicht zu lang wird. Sieht doch gar nicht schlecht aus. Sollte ich mal versuchen das Automatic Acoustic Management zu aktivieren ? Sollte sie zwar nicht schneller aber vielleicht etwas leiser machen. Und was hat es mit dem AHCI im Bios auf sich ? Meine Hardware/BIOS Kenntnisse sind noch aus Pentium, pre-ATA Zeiten.

Aja: Lenny 2.6.26-1-amd64

[cirrussc]

Hier könnte eventuell das Problem liegen, da kein DMA Modus als aktiv angezeigt wird:[...]

Bei SATA Festplatten ist DMA immer aktiviert und lässt sich auch nicht abstellen, angezeigt wird es von hdparm leider nicht.

Ich würde als erstes einen neuen Kernel (2.6.28 oder zuerst 2.6.26 aus Lenny) ausprobieren.

Dem schließe ich mich trotzdem an.

Sollte ich mal versuchen das Automatic Acoustic Management zu aktivieren ?

Brauchst Du nicht, deine Platte unterstützt dieses Feature nicht. Angezeigt von dem nicht vorhandenem Stern.

Und was hat es mit dem AHCI im Bios auf sich ?

Ist eine Standard für SATA Platten, sollte dich also noch nicht interessieren müssen

http://de.wikipedia.org/wiki/Advanced_H ... _Interface

[OppaErich]

Sollte ich mal versuchen das Automatic Acoustic Management zu aktivieren ?

Brauchst Du nicht, deine Platte unterstützt dieses Feature nicht. Angezeigt von dem nicht vorhandenem Stern.

Naja, ich hab es mal auf 128 gesetzt und nun ist ein Stern dran. Soll angeblich das leiseste aber auch langsamste sein. Ich höre keinen Unterschied und hdparm -tT zeigt sogar leicht höhere Werte.

Und was hat es mit dem AHCI im Bios auf sich ?

Ist eine Standard für SATA Platten, sollte dich also noch nicht interessieren müssen
http://de.wikipedia.org/wiki/Advanced_H ... _Interface

Danke für den Link. Bei mir ist es auf IDE gesetzt, glaube ich. Da Du Standard sagst, vermute ich mal der Kernel redet direkt mit dem Controller und lässt das BIOS links liegen.
Tja, Schade eigentlich, wäre wohl zu einfach gewesen. Dann warte ich mal auf den 28er Kernel.

[TRex]

Back dir doch selbst einen. Der läuft auch in der Standardkonfiguration (also entpacken, kompilieren, installieren) ganz gut. Und wenn du zusätzliche Ideen hast, baust du die eben ein.

[PapaNissje]

So, ich habe mir nun einen neuen Kernel gebaut (2.6.28). Keine Besserung. Das Witzige an der Sache:

Ich hatte das gleiche problem mit meinem vorhergehenden Rechner (Core2Duo). Das einzige, was gleich ist, ist die Festplatte und die Kernelkonfiguration. Eventuell muss ich am Kernel schrauben. Nur wo?

Gruß
PapaNissje

[PapaNissje]

Noch eine wunderliche Entdeckung:

Ich habe mal versucht eine mächtig große Datei (ca. 600MB) mittels mc zu kopieren. Dabei komme ich auf maximal 10MB/s. Das ist doch etwas wenig.... top gibt dabei einen hohen Wert für wa aus, also IO Wait (ca. 80%). Bringt euch das weiter?

Bei http://www.linux-ata.org habe ich ein wenig über SATA und Linux gelesen. Die empfehlen AHCI zu verwenden. Also AHCI im bios und den Treiber im Kernel. Habe ich gemacht, aber ohne Besserung Die Waits sind immernoch sehr hoch. Komisch ist nur, warum ein echtes Kopieren mittels MidnightCommander ein so gravierend anderes Ergebnis bringt wie hdparm -t.

Gruß
PapaNissje

[OppaErich]

Hehe, das mit dem AHCI habe ich auch versucht. Einziger "Erfolg": Windows bootet nicht mehr, führt zu einem Kaltstart. Ich hab' Xubuntu jetzt durch sidux ersetzt und da auch den 28er Kernel. Auch nicht schneller, als ich mein Home rüberkopiert habe kam ich auf 8-9 MB/s. Weiß jemand was da alle 5-10 Sekunden auf die Platte schreibt ? Nervt etwas dieses Kaalack alle paar Sekunden.

[cirrussc]

Komisch ist nur, warum ein echtes Kopieren mittels MidnightCommander ein so gravierend anderes Ergebnis bringt wie hdparm -t.

Hdparm misst auf der HDD selbst ohne FS und damit ohne FS-Overhead!
Es kann also nur noch was mit deinem FS zu tun haben.

[PapaNissje]

Und was kann ich da testen/prüfen?

Gruß
PapaNissje

[OppaErich]

Oops, war falsch abgebogen...