| View previous topic :: View next topic |
| Author |
Message |
mattes
Apprentice
Joined: 23 Jul 2008
Posts: 263
Location: München, Bavaria, Germany
|
 Posted: Thu Jan 21, 2010 5:07 pm Post subject: Kernel 2.6.32 -> Hänger bei I/O Operationen |
 |
|
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
Mattes
Last edited by mattes on Sun Feb 07, 2010 9:59 am; edited 1 time in total |
|
| Back to top |
|
 |
ChrisJumper
Advocate
Joined: 12 Mar 2005
Posts: 2403
Location: Germany
|
| Posted: Thu Jan 28, 2010 3:50 pm Post subject: |
|
|
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) |
|
| Back to top |
|
|
mattes
Apprentice
Joined: 23 Jul 2008
Posts: 263
Location: München, Bavaria, Germany
|
| Posted: Sun Feb 07, 2010 9:58 am Post subject: |
|
|
Hallo,
da Ganze hat bei mir erst mit dem Wechsel auf 2.6.32 angefangen.
Wenn ich ein | Code: | | 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 |
|
| Back to top |
|
|
mattes
Apprentice
Joined: 23 Jul 2008
Posts: 263
Location: München, Bavaria, Germany
|
| Posted: Sun Feb 07, 2010 10:29 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
mattes
Apprentice
Joined: 23 Jul 2008
Posts: 263
Location: München, Bavaria, Germany
|
| Posted: Sun Feb 07, 2010 2:11 pm Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
ChrisJumper
Advocate
Joined: 12 Mar 2005
Posts: 2403
Location: Germany
|
| Posted: Mon Feb 08, 2010 5:18 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
|
| Back to top |
|
|
ChrisJumper
Advocate
Joined: 12 Mar 2005
Posts: 2403
Location: Germany
|
| Posted: Mon Feb 08, 2010 9:32 pm Post subject: |
|
|
| 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:
| Code: |
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
|
|
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
|
| Back to top |
|
|
ChrisJumper
Advocate
Joined: 12 Mar 2005
Posts: 2403
Location: Germany
|
| Posted: Tue Feb 09, 2010 1:55 am Post subject: |
|
|
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:
| Code: | # 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 |
|
| Back to top |
|
|
mattes
Apprentice
Joined: 23 Jul 2008
Posts: 263
Location: München, Bavaria, Germany
|
| Posted: Fri Feb 12, 2010 5:14 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Sat Feb 13, 2010 8:41 pm Post subject: |
|
|
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
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa
Hardcore Gentoo Linux user since 2004  |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
|
| Back to top |
|
|
ChrisJumper
Advocate
Joined: 12 Mar 2005
Posts: 2403
Location: Germany
|
| Posted: Fri Feb 19, 2010 8:38 pm Post subject: |
|
|
| 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? |
|
| Back to top |
|
|
schachti
Advocate
Joined: 28 Jul 2003
Posts: 3765
Location: Gifhorn, Germany
|
| Posted: Sat Feb 20, 2010 6:31 am Post subject: |
|
|
@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. 
_________________
Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
| Back to top |
|
|
Tinitus
Veteran
Joined: 20 Sep 2004
Posts: 1754
|
| Posted: Sat Feb 20, 2010 12:29 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
ChrisJumper
Advocate
Joined: 12 Mar 2005
Posts: 2403
Location: Germany
|
| Posted: Sat Feb 20, 2010 4:51 pm Post subject: |
|
|
| 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... |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Sat Feb 20, 2010 6:17 pm Post subject: |
|
|
| ChrisJumper wrote: | | 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.
[snip] ... [snip]
|
kein Problem das "real life" geht ja schließlich vor - von Luft, Liebe und gutem Willen kann man schließlich nicht leben
gut, dass es jetzt besser geht,
vielleicht lag es an einem nicht korrekt funktionierendem NCQ - dieses einmal versuchen zu deaktivieren:
| Code: | 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.
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... |
hihi genau ^^
du nimmst mir das Wort aus dem Mund, ChrisJumper
| 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?
2. Eine Software die solche Werte zum "lernen" auswertet, den Kernel modifiziert und sich an die (unterschiedlichen) Desktops/User anpasst? |
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 ...
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa
Hardcore Gentoo Linux user since 2004 |
|
| Back to top |
|
|
Josef.95
Advocate
Joined: 03 Sep 2007
Posts: 4691
Location: Germany
|
| Posted: Sat Feb 20, 2010 6:58 pm Post subject: |
|
|
| 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?! |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Sun Feb 21, 2010 12:15 pm Post subject: |
|
|
| 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
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 
naja - egal, momentan gibt es eh keine genetic Scheduler für 2.6.33 oder 2.6.32 ...
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa
Hardcore Gentoo Linux user since 2004 |
|
| Back to top |
|
|
|
Deutsches Forum (German)
