# Kernel 2.6.32 -> Hänger bei I/O Operationen

## mattes

Hallo,

habe seit einigen Tagen den Kernel gentoo-sources-2.6.32-r1 im Einsatz. Seit dem kommt es während "arbeitsintensiver"  Tasks zu Hängern. Maus bewegt sich, aber z.B. Fenster wechseln nicht mehr. Das tritt z.b. beim Compilieren vor, aber nicht immer. Hat von euch Jemand eine Idee woran das liegt? Wahrscheinlich hab ich irgendwas nicht gut konfiguriert.

Grüße

MattesLast edited by mattes on Sun Feb 07, 2010 9:59 am; edited 1 time in total

----------

## ChrisJumper

Ach genau das stört mich garde auch, besonders auf langsamen Systemen.

Und um der Sache auf den Grund zu gehen bin ich über diesen Thread gestolpert.

Ich werde das heute nachmittag mal ausprobieren, aber auch gleichzeitig auf den Kernel 2.6.32-r1 umsteigen. Benutze momentan mit dem 2.6.31-r4.

Keine Besserung durch Deadline-IO-Scheduler. Ein echo 1 >> /sys/block/$disk/queue/iosched/quantum stand bei mir nicht zur Verfügung, hab dort nur: fifo_batch  front_merges  read_expire  write_expire  writes_starved

 Jetzt schau ich mir mal die zen-source an. An dieser Stelle noch ein Link zu einem Thema in diesem Forum:

AMD64 system slow/unresponsive during disk access

AMD64 system slow/unresponsive during disk access (Part 2)

----------

## mattes

Hallo,

da Ganze hat bei mir erst mit dem Wechsel auf 2.6.32 angefangen. 

Wenn ich ein  

```
emerge --sync && eix-update
```

 laufen lasse, kann ich de fakto nicht mehr mit dem Desktop arbeiten. 

So kann das definitiv nicht bleiben. Als I/O Scheduler habe ich immer schon den CFQ gehabt, der sollte eigentlich für mich auch optimal arbeiten.

Aber es gibt ja derzeit Umbauten wegen ControlGroups vielleicht hängt das Problem damit zusammen? 

Kann ich das durch Einstellungen irgendwie verbessern?

Grüße

Mattes

----------

## mattes

Hab deine Links mal gelesen und werde die Optionen probieren.

Das komische ist, dass bei den meisten Leuten das Problem früher bestand, und mit 2.6.32 besser wurde, genau das Gegenteil von dem was ich bei mir beobachte...

EDIT:Typo

----------

## mattes

 *ChrisJumper wrote:*   

> 
> 
>  Jetzt schau ich mir mal die zen-source an.

 

Das hab ich auch gerade getan. Mit dem BFQ Scheduler scheint es wunderbar zu laufen. Werde das die nächsten Tage mal ausführlich testen und hier berichten.

Grüße

Mattes

----------

## ChrisJumper

Der Zen-Kernel läuft hier auch recht gut, allerdings kann ich damit keine spiele Spielen ohne das sich mein kompletter X-Server nicht hin und wieder schließt und neustartet, mit dem normalen gentoo-sources (2.6.32-r2) hab ich dieses Problem nicht.

Damit man sich vorstellen kann wie langsam es dann zugeht:

Wenn ich ein via Wine eine 4 GB Spiel installiere dauert dies gut und gerne 2 Stunden, wären dessen dauert die Abfrage der Verzeichnisstruktur ls /usr/ schon real 4m3.844s :)

Mit den Zen-Sourcen ist es Gefühlt angenehmer, allerdings wird das System immer noch sehr träge wenn ich eine wine-Installation starte. Ist der RAM mit IO-Cache voll, braucht ein Browserstart auch 1min und mehr.

Edit: Wobei ich grade eine Installation mit Zen Sourcen teste. Hier sind die Effekte auch so. Nebenbei läuft iotop[/] und [i]htop weder der Prozessor ist ausgelastet noch die Festplatte. Die Load average zeigt folgende Werte: 3.11 3.33 2.88

Langsam glaube ich nicht das dieses Verhalten (bei dem Rechner) "nur" an dem Scheduler liegt. Ich hab übrigens den BFQ ausprobiert.

----------

## kernelOfTruth

nutzt ihr den CFQ i/o scheduler und ist low_latency auf 1 gesetzt ?

damit + BFS läuft das System unter Last recht rund für mich   :Smile: 

----------

## ChrisJumper

 *Quote:*   

> nutzt ihr den CFQ i/o scheduler und ist low_latency auf 1 gesetzt ?
> 
> 

 

Wo finde ich denn diese Opiton? Zuerst dachte ich es wäre ein Modul oder dergleichen..  aber im Kernel hab ich das noch nicht gefunden. Oder aktiviert man das im /sys/ Verzeichnis?

Bei /sys/block/sda/queue/iosched/ hab ich nur folgende Einstellungsmöglichkeiten:

```

back_seek_max

back_seek_penalty

desktop

fifo_expire_async

fifo_expire_sync

max_budget

max_budget_async_rq

quantum

slice_idle

timeout_async

timeout_sync

```

----------

## kernelOfTruth

 *ChrisJumper wrote:*   

>  *Quote:*   nutzt ihr den CFQ i/o scheduler und ist low_latency auf 1 gesetzt ?
> 
>  
> 
> Wo finde ich denn diese Opiton? Zuerst dachte ich es wäre ein Modul oder dergleichen..  aber im Kernel hab ich das noch nicht gefunden. Oder aktiviert man das im /sys/ Verzeichnis?
> ...

 

laut einschlägigen Sites gibt es die Option ab 2.6.32:

 CFQ low latency mode 

davor hieß das ganze: desktop

setze das probeweise also mal auf "1" 

Standardmäßig ist es mit 2.6.32-rc3 wohl aktiviert gewesen und nach rc6 wieder deaktiviert worden - andererseits soll es (ab 2.6.32 final) immer an sein. Egal was jetzt stimmt - einfach mal aktivieren, wenn es nicht an ist ...

 2.6.32 is Out! But a Word of Caution Around CFQ 

----------

## ChrisJumper

Danke kernelOfTruth,

mit dem Kernel 2.6.32-r3 und CFQ + low_latancy läuft es besser. Das Problem meiner wine-Installation ist allerdings noch nicht behoben, liegt aber vielleicht doch an der Festplatte und meiner Partition..?

Installiere ich diese Applikation auf der selben Festplatte (sda), aber einer andren Partition (sda7), wie mein Root-Verzeichnis (sda1), kommt es zu den performance Einbrüchen.

Wenn ich jetzt drüber nachdenke, liegt es vielleicht daran das der Lesekopf dabei so große Distanzen zurücklegen muss...? Die Platte selber:

```
# fdisk -l /dev/sda

Platte /dev/sda: 250.1 GByte, 250059350016 Byte

255 Köpfe, 63 Sektoren/Spur, 30401 Zylinder

Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes

..

/dev/sda2              21       12470   100004625   83  Linux

..

/dev/sda7           24208       28208    32138001   83  Linux

....

```

Grüße

Edit: Nur zur Information. Meine SDA-Festplatte lässt mich hängen. Sie reagiert beim Kopieren von größeren Dateien nicht mehr und es dauert Minuten bis sie wieder reagiert. Also an meinem Problem war nur minimal der Kernel schuld. Bei einem Defekt hätte ich erwartet das sie GAR nicht mehr geht, oder eine Fehlermeldung auswirft. Statt dessen gab es DMA Fehlermeldungen, verlangsamte Zugriffe und Co.Last edited by ChrisJumper on Fri Feb 12, 2010 5:36 pm; edited 1 time in total

----------

## mattes

Hallo,

also mit den Zen-Sources läuft es hier deutlich besser. Bei update-eix habe ich noch ein leichtes Ruckeln, aber ansonsten läuft alles sehr flüssig. 

Verwende BFS und BFQ.

Guter Tipp, danke!

Grüße

Mattes

----------

## kernelOfTruth

Bitte, gerne ChrisJumper,

installier einmal iotop und lass es einmal laufen, wenn du große Mengen kopierst was für einen Transferrate es ausgibt

weiterhin könnten hilfreich folgende Werte niedrig einzustellen (so zwischen 1-5):

/proc/sys/vm/dirty_background_ratio

/proc/sys/vm/dirty_ratio

den CFS-Scheduler schneller reagieren lassen:

echo "100000" > /proc/sys/kernel/sched_latency_ns

#echo "10000000" > /proc/sys/kernel/sched_latency_ns

### default: 10000000 (10.000.000)

echo "200000" > /proc/sys/kernel/sched_min_granularity_ns

## #echo "2000000" > /proc/sys/kernel/sched_min_granularity_ns

### default: 2000000 (2.000.000)

echo "1000000" > /proc/sys/kernel/sched_wakeup_granularity_ns

#echo "2000000" > /proc/sys/kernel/sched_wakeup_granularity_ns

### default: 2000000 (2.000.000)

BFS-Scheduler schneller reagieren lassen:

echo "3" > /proc/sys/kernel/rr_interval

# recommendation from oracle: set max_sectors_kb low to 64 and read_ahead_kb to 16384 / 4096

for i in /sys/block/sd*; do

         /bin/echo "16384" >  $i/queue/read_ahead_kb

         /bin/echo "64" >  $i/queue/max_sectors_kb

	 /bin/echo "1"   >  $i/queue/rq_affinity

#         /bin/echo "0"   >  $i/queue/nomerges

done

for i in /sys/block/sd*; do

         /bin/echo "cfq" >  $i/queue/scheduler

         /bin/echo "16" >  $i/queue/iosched/quantum # default: 4

         /bin/echo "1" >  $i/queue/iosched/low_latency # default: 1

         /bin/echo "2048" >  $i/queue/nr_requests

done

# generellen read_ahead für BDI unter 2.6.33 erhöhen

echo 4096 > /sys/class/bdi/default/read_ahead_kb

----------

## kernelOfTruth

@ChrisJumper:

gibt es Neuigkeiten von deiner Seite ?

hast du die Sachen in meinem letzten Post ausprobiert ?

----------

## ChrisJumper

 *kernelOfTruth wrote:*   

> @ChrisJumper:
> 
> gibt es Neuigkeiten von deiner Seite ?
> 
> hast du die Sachen in meinem letzten Post ausprobiert ?

 

Oh entschuldige, ich hatte die letzten Tage nicht so viel Zeit um im Forum zu lesen und ärger mit einem anderen (neuen) Computer.

Also ich hab folgendes gemacht: Nachdem ich durch Zufall bemerkte das sich eine Wine-Applikation in ca. 30-40 minuten auf einer anderen Festplatte installieren lässt (ich habe hier nur Sata-Platten), und auf der "Root"-Festplatte fast 3 Stunden brauchte. Mein Windows platt gemacht und gentoo-root auf dessen Festplatte geklont und die alte gentoo-root Platte entfernt. Seit dem bin ich wieder glücklich. Jetzt benutze ich auch wieder die Zen-Sourcen und anders als vorher, habe ich keine Nebenwirkungen. Wenn ich am Sonntag/Montag mal Zeit habe, werde ich deine Ratschläge nochmal ausprobieren.

Allerdings werde ich nicht mehr die andere Festplatte als Root-Platte nehmen sondern höchsten Daten auf diese kopieren. Es ist so merkwürdig bisher dachte ich immer wenn es zu Fehlern mit den Festplatten kommt, das diese im messages-Log landen oder sie wenigstens von dmesg angezeigt werden. Aber hier machte sich ja kein Fehler bemerkbar. Es schient lediglich das der Kernel manchmal Minuten lang auf eine Reaktion der Festplatte wartet (aber ohne Grund, nicht weil z.B. ein anderer Prozess darauf zugreift.).

Ich hatte ja auch iotop installiert oder halt htop auf.. aber "ich schätze" diese Programme hingen auch und haben keine besonderen Werte angezeigt, da sie auf eine Rückmeldung der Festplatte warten. Sonderbar. Aber jetzt ist alles wieder normal, also viel besser als vorher. Habe jetzt aber auch den Kernel 2.6.32 mit low_latancy bzw. Oder seit drei Tagen wieder den Zen-kernel mit BFQ + BFS, alles bestens. :)

OT:

Gibt es eigentlich schon ein Projekt,das

1. solche Werte aufzeichnet und sammelt (möglichst anonym) und als Feedback den Entwickler zur Verfügung stellt?

2. Eine Software die solche Werte zum "lernen" auswertet, den Kernel modifiziert und sich an die (unterschiedlichen) Desktops/User anpasst?

----------

## schachti

@kernelOfTruth: Woher hast Du diese Tuning-Tipps, was genau machen sie, und warum besteht die Hoffnung, die Kiste dadurch schneller zu machen? Bin kein Freund von schwarzer Magie sondern weiss stattdessen gerne, was ich dort ändere, bevor ich es tue.   :Wink: 

----------

## Tinitus

Hallo,

habe gleiches Verhalten beim kopieren von vielen Dateien.

Das geht so weit, daß zwischenzeitlich der Mauszeiger hängt. Tastatureingaben im Nirvana verschwinden. etc.

G. R.

----------

## ChrisJumper

 *schachti wrote:*   

> @kernelOfTruth: Woher hast Du diese Tuning-Tipps, was genau machen sie, und warum besteht die Hoffnung, die Kiste dadurch schneller zu machen? Bin kein Freund von schwarzer Magie sondern weiss stattdessen gerne, was ich dort ändere, bevor ich es tue.  :wink:

 

Also ich vermute KernelOfTruth hat das Wissen dieser schwarzen Magie von diversen Kernelmailing-Listen und aus Artikeln von kernelnewbies.org/heise.de

(Siehe Links aus seinem zweiten Post vom 8 Februar, und seinen Posts im Thread "AMD64 system slow/unresponsive during disk access (Part 2)".) Dort ist auch einiges dazu erklärt.

Hab jetzt aber auch keine Hänger mehr oder dergleichen.

Oh und achtet doch mal bitte darauf welches Dateisystem auf der Platte ist die grade IO lastig ist...

----------

## kernelOfTruth

 *ChrisJumper wrote:*   

>  *kernelOfTruth wrote:*   @ChrisJumper:
> 
> gibt es Neuigkeiten von deiner Seite ?
> 
> hast du die Sachen in meinem letzten Post ausprobiert ? 
> ...

 

kein Problem das "real life" geht ja schließlich vor - von Luft, Liebe und gutem Willen kann man schließlich nicht leben   :Wink: 

gut, dass es jetzt besser geht,

vielleicht lag es an einem nicht korrekt funktionierendem NCQ - dieses einmal versuchen zu deaktivieren:

```
for i in /sys/block/sd*; do

         /bin/echo "1" >  $i/device/queue_depth

done
```

"0" geht nicht - in dem Fall wäre es global für alle Laufwerke, um es nur auf einem zu deaktivieren:

echo "1" > /sys/block/sda/queue/device/queue_depth 

falls das nichts bringt:

echo "0" > /sys/block/sda/queue/iosched/slice_idle # default: 6, 0 fixes ncq BUG

die beiden Einstellungen bei queue_depth und slice_idle sollten eigentlich mit 2.6.32, 2.6.33 nicht mehr nötig sein; evtl bringt es aber dennoch etwas

 *ChrisJumper wrote:*   

>  *schachti wrote:*   @kernelOfTruth: Woher hast Du diese Tuning-Tipps, was genau machen sie, und warum besteht die Hoffnung, die Kiste dadurch schneller zu machen? Bin kein Freund von schwarzer Magie sondern weiss stattdessen gerne, was ich dort ändere, bevor ich es tue.   
> 
> Also ich vermute KernelOfTruth hat das Wissen dieser schwarzen Magie von diversen Kernelmailing-Listen und aus Artikeln von kernelnewbies.org/heise.de
> 
> (Siehe Links aus seinem zweiten Post vom 8 Februar, und seinen Posts im Thread "AMD64 system slow/unresponsive during disk access (Part 2)".) Dort ist auch einiges dazu erklärt.
> ...

 

hihi genau ^^

du nimmst mir das Wort aus dem Mund, ChrisJumper   :Wink: 

 *ChrisJumper wrote:*   

>  OT: 
> 
> Gibt es eigentlich schon ein Projekt,das 
> 
> 1. solche Werte aufzeichnet und sammelt (möglichst anonym) und als Feedback den Entwickler zur Verfügung stellt? 
> ...

 

zu 1.

mir sind nur klive und kerneloops bekannt also nichts wirklich zutreffendes

zu 2.

die gibt bzw. gab es: die genetic library and damit verbunden

der genetic anticipatory scheduler (i/o scheduler) [zuletzt in den Zen-sources -> jetzt Zen-Kernel genannt] und der zaphod scheduler (cpu scheduler)

das problem von solchen Lösungen ist die erhöhte Latenz beim Hochfahren - nach längerer Laufzeit rechnet sich das ganze, sinnvoll wäre es - wenn es eine Möglichkeit gäbe, die bereits etablierten (evolutionär "fitteren") Einstellungen abzuspeichern bzw. zu notieren und mit diesen das nächste Mal beginnen zu können

aus dem Problem mit der erhöhten Latenz ist klar, dass es hauptsächlich auf Servern mehr Sinn machen würde

was für Neuigkeiten es jetzt aus diesem Bereich gibt, weiß ich nicht - ich bin mit CFQ low latency, BFS und den geposteten Tweaks recht zufrieden ...

----------

## Josef.95

 *kernelOfTruth wrote:*   

> das problem von solchen Lösungen ist die erhöhte Latenz beim Hochfahren - nach längerer Laufzeit rechnet sich das ganze, sinnvoll wäre es - wenn es eine Möglichkeit gäbe, die bereits etablierten (evolutionär "fitteren") Einstellungen abzuspeichern bzw. zu notieren und mit diesen das nächste Mal beginnen zu können

 Bin mir da nun nicht ganz sicher, aber sollte man das nicht in der /etc/sysctl.conf dauerhaft setzen können?!

----------

## kernelOfTruth

 *Josef.95 wrote:*   

>  *kernelOfTruth wrote:*   das problem von solchen Lösungen ist die erhöhte Latenz beim Hochfahren - nach längerer Laufzeit rechnet sich das ganze, sinnvoll wäre es - wenn es eine Möglichkeit gäbe, die bereits etablierten (evolutionär "fitteren") Einstellungen abzuspeichern bzw. zu notieren und mit diesen das nächste Mal beginnen zu können Bin mir da nun nicht ganz sicher, aber sollte man das nicht in der /etc/sysctl.conf dauerhaft setzen können?!

 

wir reden hier von genetic schedulern  :Wink: 

der Sinn ist ja nicht es fest einzustellen, sondern mit den letzten besten Einstellungen neu zu booten

ich hab es in der Vergangenheit auch schon versucht, es hat aber leider nichts gebracht - der/die Scheduler haben meine Einstellungen nicht berücksichtigt und mit ihren weitergemacht   :Confused: 

naja - egal, momentan gibt es eh keine genetic Scheduler für 2.6.33 oder 2.6.32 ...

----------

