[erledigt] historisches Sticky-Bit-Verhalten reaktivieren?

[hikaru]

Hallo,

ich bin gerade über den Wikipedia-Artikel zum Sticky-Bit gestolpert [1] und lese dort das:

In seiner ursprünglichen Bedeutung wurde das Sticky-Bit bei ausführbaren Dateien, also Programmen mit Ausführ-Dateirechten, angewendet. Es bewirkte, dass das Programm nach Beendigung des dazugehörigen Prozesses nicht aus dem Arbeitsspeicher entfernt und somit bei einem erneuten Aufruf des Programms nicht noch einmal vom Sekundärspeicher (z. B. Festplatte) in den Primärspeicher (Arbeitsspeicher) geladen und neu reloziert werden musste.

...aber leider auch dies:

Diese Funktion ist als historisch zu betrachten, sie ist auf modernen Unix-Derivaten in der historischen Form nicht mehr implementiert.

Lässt sich dieses historische Verhalten irgendwie reaktivieren oder auf andere Art erzeugen?

Angesichts dessen dass das der Beschreibung nach nur bei statisch gelinkten Programmen wirklich Sinn ergeben würde wäre eine alternative Lösung die auch die geladenen Libs im Speicher hält vielleicht die bessere Wahl.

[1] http://de.wikipedia.org/wiki/Sticky_Bit

[Meillo]

Lässt sich dieses historische Verhalten irgendwie reaktivieren oder auf andere Art erzeugen?

Wieso? Denn:

Das ganze macht nur Sinn bei wenig Speicher und langsamen Platten; hier kann es dazu kommen, das ein Programm in den Speicher geladen wird und sich dann quasi selbst mit den Ergebnissen der eigenen Arbeit überschreibt - was die Performance in den Keller bringt, muß doch das Programm dauernd neu eingeladen werden. Diese Funktionalität ist heute tot, denn es gibt demand paging etc.

http://doc-tcpip.org/Unix/stickybit.html


Zur Verbreitung findest du in der englischen Wikipedia deutlich mehr. Z.B.:

Currently, this behavior is only operative in HP-UX, NetBSD, and UnixWare. Solaris appears to have abandoned this in 2005.[citation needed] The 4.4-Lite release of BSD retained the old sticky bit behavior but it has been subsequently dropped from OpenBSD (as of release 3.7) and FreeBSD (as of release 2.2.1); it remains in NetBSD. No version of Linux has ever supported this traditional behavior.

http://en.wikipedia.org/wiki/Sticky_bit

[hikaru]

Wieso?

Mein HTPC (ein zweckentfremdetes Netbook), auf dem ich abends gern mal einen Film schaue oder morgens mal Nachrichten lese hat 2GB RAM und verträgt nicht mehr.
Da er tagsüber regelmäßig Backups von meiner Arbeit zieht läuft er die ganze Zeit, hat aber eigentlich kaum was zu tun. Um seinen Tagesablauf etwas mehr auszufüllen verteilt er Debian-Images per Torrent. Tagsüber und Nachts fluten diese Images den gesamten RAM, so dass ich abends beim Starten des Videospielers oder morgens beim Browserstart immer erst warten muss bis er den dafür nötigen Platz im RAM freigeschaufelt hat.
Insofern habe ich also "wenig" Speicher, denn um alle Torrents unterzubringen bräuchte ich zweistellige GB an RAM und auch die Platte ist "langsam" denn sie ist ja ständig damit beschäftigt noch nicht im RAM liegende Torrent-Chunks nachzuliefern.

Wenn ich nun dafür sorgen könnte dass der Videospieler und der Browser in meiner Abwesenheit nicht wieder aus dem RAM fliegen könnte ich einiges an Wartezeiten (derzeit jeweils ca. 1 Minute) deutlich reduzieren. Einmal im RAM laufen die Programme mit normaler Geschwindigkeit. Für die Torrents hingegen ist es ziemlich egal ob sie im RAM rumlungern oder nicht.

Edit:
Die Programme ständig offen zu lassen ist leider auch keine Lösung, denn da werden sie bei Bedarf auch aus dem RAM ausgelagert, nur eben dann mit offenem Fenster.

[Meillo]

Wenn ich nun dafür sorgen könnte dass der Videospieler und der Browser in meiner Abwesenheit nicht wieder aus dem RAM fliegen könnte ich einiges an Wartezeiten (derzeit jeweils ca. 1 Minute) deutlich reduzieren. Einmal im RAM laufen die Programme mit normaler Geschwindigkeit. Für die Torrents hingegen ist es ziemlich egal ob sie im RAM rumlungern oder nicht.

Das macht Sinn. Mit Linux wirst du da aber nicht weiter kommen.

Vielleicht kannst du mit `ulimit' aehnliches erreichen indem du dem Torrent-Prozess nur die Nutzung eines Teils des Arbeitsspeichers erlaubst.

[nudgegoonies]

Code: Alles auswählen

Die Programme ständig offen zu lassen ist leider auch keine Lösung, denn da werden sie bei Bedarf auch aus dem RAM ausgelagert, nur eben dann mit offenem Fenster.

Vielleicht die swappieness auf 0 setzen und doch die Programme durchlaufen lassen? Dann sollte der Blockcache eigentlich keine Priorität mehr vor anderen belegten Speicherseiten haben und gar nicht mehr ausgelagert werden, außer ein Programm beansprucht wirklich mehr RAM als noch verfügbar. Und wenn ich Torrent richtig verstehe, braucht es ja gar nicht so viel RAM zum Verteilen sondern greift halt auf riesige Dateien und das an verschiedenen Stellen gleichzeitig und darum wächst der Blockcache gen Maximum und wenn die swappieness größer 0 ist lagert Linux er halt Speicherseiten aus die momentan nicht benutzt werden.

[hikaru]

Vielleicht kannst du mit `ulimit' aehnliches erreichen indem du dem Torrent-Prozess nur die Nutzung eines Teils des Arbeitsspeichers erlaubst.

Das Problem ist, dass nicht der Prozess selbst so viel Speicher belegt sondern wie nudgegoonies richtig darstellt der Cache vollgeschrieben wird.

Vielleicht die swappieness auf 0 setzen und doch die Programme durchlaufen lassen? Dann sollte der Blockcache eigentlich keine Priorität mehr vor anderen belegten Speicherseiten haben und gar nicht mehr ausgelagert werden, außer ein Programm beansprucht wirklich mehr RAM als noch verfügbar.

Das habe ich schon probiert. Ich muss ehrlich sagen dass ich mich mit dem Verständnis der Swappiness etwas schwer tue (theoretisch verstehe ich es glaube ich, ich sehe aber keine Effekte die ich mit der Theorie in Einklang bringen kann). Aber ich habe in den vergangenen Monaten schon mit rund einem Dutzend Werten zwischen 0 und (rein aus Neugier) 100 gearbeitet und keine signifikanten positiven Effekte gesehen.
Im Moment fahre ich eine Radikallösung ganz ohne Swap und die fühlt sich genauso an wie eine Lösung mit 2GB Swap ohne Anpassung der Swappiness bei der aber immer nur rund 300MB des Swap beschrieben wurden. D.h. selbst ohne Swap sind die offenen Fenster bei der ersten Bedienung nach mehreren Stunden wieder so träge wie bei einem Neustart, als würde alles frisch von der beschäftigen Festplatte geladen.
Das einzige was mal einen wirklichen Schub gebracht hat war der Einsatz von zram [1], aber das lief nicht stabil [2], selbst nach regelmäßigem Ein- und Aushängen nicht, da sich die Aufhänger letztendlich doch als zufällig und nicht zeitabhängig herausgestellt haben.

[1] http://wiki.ubuntuusers.de/zRam
[2] viewtopic.php?f=33&t=138079

[nudgegoonies]

Im Moment fahre ich eine Radikallösung ganz ohne Swap und die fühlt sich genauso an wie eine Lösung mit 2GB Swap ohne Anpassung der Swappiness bei der aber immer nur rund 300MB des Swap beschrieben wurden. D.h. selbst ohne Swap sind die offenen Fenster bei der ersten Bedienung nach mehreren Stunden wieder so träge wie bei einem Neustart, als würde alles frisch von der beschäftigen Festplatte geladen.

Verstehe ich das richtig, dass Du den selben Effekt ganz ohne Swap hast? Das wäre in der Tag ein sehr merkwürdiges Verhalten da in dem Fall ja gar nichts eingelagert werden muss.

Es spricht aber dafür, dass Du eigentlich genug RAM hast. Und da sind wir wieder beim Blockcache, den man, meinem Googleergebnissen nach, nicht auf einen Maximalwert beschränken kann.

Ich bin noch auf ein Ergebnis gestoßen, dass swappiness = 0 nur im Verbund mit vfs_cache_pressure = 0 etwas bringen soll. Swappiness habe ich zwar verstanden, aber vfs_cache_pressure nicht

Ein Schuss ins Blaue von mir wären noch die transparent Hugepages. Ich kann es mir aber ehrlich gesagt nicht vorstellen, dass die Speicherseiten vom Torrentprogramm und vom Blockcache alle so intensiv defragmentiert werden, dass sie alle in 4MB Seiten passen und danach der Rest so total fragmentiert ist, dass bei der Wiederbenutzung der Daemon anfängt diese zu defragmentieren und in 4MB Seiten zu pressen.

Weiter weiß ich im Moment leider auch nicht

http://wiki.debianforum.de/Debian_auf_dem_DesktopHier steht etwas zu vfs_cache_pressure.

[hikaru]

Verstehe ich das richtig, dass Du den selben Effekt ganz ohne Swap hast? Das wäre in der Tag ein sehr merkwürdiges Verhalten da in dem Fall ja gar nichts eingelagert werden muss.

Ja. Und Ja.

Es spricht aber dafür, dass Du eigentlich genug RAM hast.

"Eigentlich" ja. Ich müsste nochmal nachschauen um sicher zu sein, aber bei der aktuellen Konfiguration sind laut top etwa 800MB reiner Cache.

Ich bin noch auf ein Ergebnis gestoßen, dass swappiness = 0 nur im Verbund mit vfs_cache_pressure = 0 etwas bringen soll. Swappiness habe ich zwar verstanden, aber vfs_cache_pressure nicht

vfs_cache_pressure lese ich gerade zum ersten mal. Damit werde ich mich mal beschäftigen. Danke für den Hinweis!

Ein Schuss ins Blaue von mir wären noch die transparent Hugepages. Ich kann es mir aber ehrlich gesagt nicht vorstellen, dass die Speicherseiten vom Torrentprogramm und vom Blockcache alle so intensiv defragmentiert werden, dass sie alle in 4MB Seiten passen und danach der Rest so total fragmentiert ist, dass bei der Wiederbenutzung der Daemon anfängt diese zu defragmentieren und in 4MB Seite zu pressen.

Hier verstehe ich (im Moment) leider nur Bahnhof.

[nudgegoonies]

Hier verstehe ich (im Moment) leider nur Bahnhof.

Ok, ich habe es auch erst verstanden nachdem ich die Vorlesungen Technische Informatik 2 und 3 gehört und mich im Praxissemester länger damit befasst habe Kurzer Erklärungsversuch: Ein Daemon defragmentiert im Hintergrund das RAM in der Art und weise, das jeweils 1024 4KB Speicherseiten an einer durch 4MB teilbaren Adresse ausgerichtet zu einer einzelnen 4MB Speicherseite zusammengefasst werden. Die Kopiererei kostet Performance und sollte eigentlich nur stattfinden, wenn das System nicht belastet ist. Aber sie bringt danach auch Performance, vor allem durch viel weniger TLB-Miss Events. Letzteres zu erklären würde den Rahmen sprengen. Aber lass Dir gesagt sein, dass jeder TLB-Miss Performance kostet

Der Daemon dazu heißt khugepaged und vielleicht ist der ja schwer beschäftigt - auch wenn er es nicht sein sollte. Überhaupt wäre ein Blick via TOP interessant was CPU-mäßig passiert sobald das System wieder interaktiv benutzt wird.

[hikaru]

So lange ich nicht aktiv bin idlet das System mehr oder weniger vor sich hin. 3-10% der CPU schluckt das Torrent-Programm, weitere 3-10% die im anderen Thread erwähnte VBox-VM und dann nochmal etwa 3-5% Kleinzeug wie Panels (Monitorplugins), xorg oder top selbst. Ich habe also im Schnitt 10-25% Grundlast.

Wenn ich aktiv werde indem ich einen Browser (meist Iceweasel) oder Videoplayer (Smplayer) starte braucht diese Anwendung inklusive Anhängsel (xulrunner) 20-40% der CPU, sie wird beim Programmstart aber nie ausgelastet. Was hoch geht ist der Load von vorher ca. 0,1 auf meist 1,8 oder ähnliche Werte. Nach allem was ich weiß passt das zu dem Umstand dass dabei Daten von einer beschäftigten HDD geladen werden (per iotop nachprüfbar).
Das Gleiche passiert auch bei einem mehrere Stunden in Ruhe aber offen gelassenen Browserfenster das nun eine an sich unspektakuläre Website laden soll. Hier eignet sich Midori zum Testen besser da Iceweasel sich auch gern mal mit sich selbst beschäftigt wenn er eigentlich nichts zu tun hat.

[wanne]

Also das Sticky-Bit würde dir auch nichts helfen, weil es nur garantiert, dass das Programm im Speicher bleibt. => Im virtullen Speicher nicht im physischen RAM.
Ohne swap und und offenem Fenster wird das Programm natürlich nicht ausgelagert.
Aber es gibt da andere Effekte: Wenn ich mit dem FF google aufrufe liest er 1466 andere Dateien als die binary vom iceweasel. Die selbst ist auch nicht das Problem Sie hat 3,2kB selsbt wenn du mit 48kiB/s (entspricht light DSL) von der HD ließt brauchst du dazu läppische 145ms. (Zum Vergleich ein beep braucht 200ms.)
Die Probleme mit denen du zu kämpfen hast sind die ganzen anderen sachen die auch noch in den RAM müssen. Außerdem deine GraKa, CPU, Bildschirm und HD die garantiert in irgend welchen energiesparmodi sind, aus denen sie wider geweckt werden müssen.
Ich glaube die sinnvollere Lösung ist, wenn du dir einfach per cron das Programm erst kurz vor nutzung öffnen lässt.

[hikaru]

Die Probleme mit denen du zu kämpfen hast sind die ganzen anderen sachen die auch noch in den RAM müssen.

Ja, die Torrent-Daten.

Außerdem deine GraKa, CPU, Bildschirm und HD die garantiert in irgend welchen energiesparmodi sind, aus denen sie wider geweckt werden müssen.

Da ist nichts in irgendeinem Energiesparmodus. Das Netbookdisplay ist permanent aus, die Ausgabe erfolgt über den angeschlossenen Fernseher. Und der ist die meiste Zeit hart aus per Steckdosenleiste. Die "Grafikarte" ist ein im CPU-Die integrierter onboard-Chip.
Und die HDD hat gar keine Zeit schlafen zu gehen denn die muss ja ständig neue Chunks nachschieben.

[wanne]

Die Probleme mit denen du zu kämpfen hast sind die ganzen anderen sachen die auch noch in den RAM müssen.

Ja, die Torrent-Daten.

Wer sich nicht ehelfen lassen will, dem kann man nicht helfen. Für das betreiben des FF muss mehr im RAM liegen nicht für die Torrents z.B. wenn du kde benutzt brauchst du kwin (das für die Torrents jetzt eher nicht gebraucht wird) das widerum ist gegen 114 weitere Dateien gelinkt dann will der FF die Einstellungen in deimen home-Ordner lesen...
Und dazu dass da nichts im energiesparmodus läuft: guck mal wie den Stromverbrauch hochgeht, wenn du dich an den Rechner setzt. Ich wette der geht hoch. (Wenn du nicht die torrents gleichzeitig abschaltest und das ganze mit nem niedrigeren CPU-Takt kompensierst.)
Und du kannst das ga ausprobieren: mit dd if=/usr/lib/iceweasel/firefox-bin of=/dev/null kannst du dir den FF ja recht einfach in den RAM holen. (Bei 2GiB RAM cachst du garantiert wenn nicht macht's deine HD (Kannst du ausprobieren indem du das widerhoslt und siehst wie schnell das dann geht...)) trotzdem wird dein System langsam bleiben.

[r900]

Aber es gibt da andere Effekte: Wenn ich mit dem FF google aufrufe liest er 1466 andere Dateien als die binary vom iceweasel.

dann will der FF die Einstellungen in deimen home-Ordner lesen...

Da ist was dran, wenn ich iceweasel das Erste mal nach dem Neustart starte rödelt auch erstmal die Festplatte und es dauert bis das Fenster endlich geöffnet ist. Und wenn noch andere Anwendungen auf die Festplatte zugreifen dauert es natürlich umso länger. Das würde auch erklären weshalb deine ganzen swapiness-Spielereien nichts bringen. Aber was macht man da am besten? ~/.mozilla als tmpfs wäre ja schön, nur werden dann keine Daten dauerhaft gespeichert was ja unter Umständen auch nicht so toll ist.

[wanne]

Wenn die torrents weiter laufen ist ionice ne möglichkeit da nachzuhelfen. Alles von hand zu treffen dürte nicht so ganz simpel sein. Wie gesagt: Der FF fasst über ein k Dateien selbst an und stößt vermutlich weitere Prozesse an, die dan widerum Dateien öffnen. Ich würde ihn einfach kurz vorher mal auf heise.de gehen lassen und mich drauf verlassen dass das caching schon alles relativ gut erledigt.

Mit nem einfachen X und nem staatisch gelinkten uzbl oder so ist das vielleicht noch möglich alles manuell in den RAM zu verschieben. Mit FF und nem richtigen WM wird das wahrscheinlich fast unmöglich.

[hikaru]

Für das betreiben des FF muss mehr im RAM liegen nicht für die Torrents z.B. wenn du kde benutzt brauchst du kwin (das für die Torrents jetzt eher nicht gebraucht wird) das widerum ist gegen 114 weitere Dateien gelinkt dann will der FF die Einstellungen in deimen home-Ordner lesen...

Natürlich muss da mehr laufen als inur der Browser. Aber ich betreibe auf einem Atom-Prozessor mit Chipsatzgrafik mit sicherheit kein fettes KDE.
Hier läuft kaum mehr als ein etwas aufgebohrtes lxde-core.

Wer sich nicht ehelfen lassen will, dem kann man nicht helfen.

Ich würde mir gern helfen lassen, nur leider scheinen deine theoretischen Überlegungen jeder praktischen Grundlage zu entbehren. Und das ist überhaupt nicht hilfreich. Falls du also sinnvolle Hinweise hast würde ich mich freuen sie zu hören, dich aber ansonsten bitten woanders deinen Senf abzugeben.

[nudgegoonies]

Im Prinzip müsste man ja einfach nur schauen, was das System genau macht, wenn Du es wieder interaktiv nutzt. Das ist bei weitem nicht so einfach, wie es klingt und viel mehr als top und iotop zu nutzen fällt mir im Moment auch nicht ein, und das hast Du ja schon gemacht.

Der Hinweis mit dem Icweweasel ist noch eine Idee Wert. Ich habe auch schon von einem Admin gehört, wie io-lastig der ist, weil er pausenlos in seinen sqlite-Datenbanken rumrödelt. Und wenn Du anfängst auf Seiten zu surfen, wo schon Teile in seinem Plattencache sind, dann fängt er erstmal an auf Platte rumzurödeln und zig kleine Dateien nachzuladen. Und vielleicht ist das der Flaschenhals, das diese Plattenoperationen 'teurer' sind als via Netz neu zu laden. Vielleicht einmal den Plattencache vom Iceweasel auf 0 setzen und schauen wie er sich verhält. Das erklärt aber nicht das Verhalten vom VLC

So rein bauchmäßig würde ich sagen das selbst ohne SWAP immer noch die Speicherorganisation irgendwie im Hintergrund rumrödelt. Der Iceweasel passt sich mit seinem RAM-Cache glaube ich auch an den aktuellen Speicherverbrauch an. Und wer weiß wer da noch 'mitspielt'.

[Six]

Der korrekte Weg wäre, die betroffenen PIDs in control groups zu stecken, denen du Resourcen so zuordnest, wie du es gern hättest.

https://www.kernel.org/doc/Documentatio ... groups.txt
https://www.kernel.org/doc/Documentatio ... memory.txt

Leider sind cgroups in Debian Squeeze aber quasi unbenutzbar. Die userspace tools sind buggy und wichtige Module (z. B. memory management) fehlen im stock 2.6.32er kernel völlig Du müsstest mindestens auf 2.6.35 aufrüsten und dir die userspace tools neu bauen. Die Quellen von Debian experimental sind anscheinend OK (Hörensagen, nicht selber ausprobiert!).

Wenn das zu viel Aufwand ist, dann versuche es doch einfach mal mit nice. Erhöhe die Priorität der dir wichtigen Programme und der Kernel behandelt die direkt besser

[hikaru]

Der Hinweis mit dem Icweweasel ist noch eine Idee Wert. Ich habe auch schon von einem Admin gehört, wie io-lastig der ist, weil er pausenlos in seinen sqlite-Datenbanken rumrödelt.

Stimmt, da könnte ich noch dran drehen. Midori verhält sich aber von den Ladezeiten her nicht viel anders als Iceweasel. Er ist gut 10 Sekunden schneller da aber das Grundproblem der langen Ladezeit bleibt.

Das erklärt aber nicht das Verhalten vom VLC

Ich nutze Smplayer, nicht VLC da ersterer auf der Atom-CPU später an seine Grenzen stößt was flüssige Videowiedergabe angeht. Ich vermute aber dass das bei den Ladezeiten des Players keinen großen Unterschied macht.

Ich habe über Nacht noch zwei Ladetests gemacht. Gestern abend habe ich einen leeren Smplayer geöffnet und Iceweasel in dem ich nur google.de (ohne Suche) angesurft habe und das die Nacht über stehen gelassen. Heute morgen habe ich zuerst ein Video im offenen Smplayer geladen. Es hat etwa 10 Sekunden gedauert bis das UI benutzbar war und ich zum Video browsen konnte. Natürlich hat das Öffnen des Videos dann deutlich länger als 10 Sekunden gedauert, aber eine Verzögerung beim UI war nach 7 Stunden Pause durchaus da.
Beim Iceweasel habe ich zuerst im Google-Tab das Webmailinterface meines Providers angesurft (SqirrelMail - etwas JavaScript aber an sich harmlos). Bis die URL-Bar bereit war hat es etwa 15 Sekunden gedauert. Der Seitenaufbau hat dann etwa 20 weitere Sekunden gedauert. Bei frisch fertig gestartetem Browser geht das auf dem Gerät in unter 5 Sekunden. Danach habe ich per Kontextmenü in einem neuen Tab über die Benachrichtigungsmail diesen Thread aufgemacht. Das Kontextmenü zu öffnen hat wiederum etwa 20 Sekunden gedauert. Danach hat alles weitere in gewohnter Geschwindigkeit funktioniert. Es scheint mir also dass Iceweasel nicht auf einen Schlag geladen wird sondern verschiedene Teile je nach Bedarf nach und nach. Es scheinen davon aber auch Teile wieder "vergessen" zu werden, denn die URL-Bar musste ja gestern Abend zum Google-Ansurfen schon mal ran und mangels Swap kann der Teil nicht dorthin ausgelagert worden sein. Andererseits habe ich bei frisch startendem Iceweasel keine gestaffelten Ladezeiten. Es dauert eine Minute bis das Fenster benutzbar ist, danach geht aber alles andere (URL-Bar, Kontextmenü) sofort.

Leider sind cgroups in Debian Squeeze aber quasi unbenutzbar. Die userspace tools sind buggy und wichtige Module (z. B. memory management) fehlen im stock 2.6.32er kernel völlig

Testweise hatte ich auf dem Rechner mal Kernel 3.2 aus den Backports installiert (wegen der zram-Geschichte aus dem anderen Thread) und irgendwann steht ja ohnehin das dist-upgrade an. Könnte mir das helfen? Über cgroups weiß ich leider nur das was vor ein paar Monaten prominent durch die Medien ging. Debianspezifisches weiß ich da gar nicht.

Die Quellen von Debian experimental sind anscheinend OK (Hörensagen, nicht selber ausprobiert!).

Hast du zufällig eine Link auf deine Hörensagen-Quelle?

Wenn das zu viel Aufwand ist, dann versuche es doch einfach mal mit nice. Erhöhe die Priorität der dir wichtigen Programme und der Kernel behandelt die direkt besser

Aber nice hilft doch nur bei CPU-Last soweit ich weiß. Bei I/O- und Loadproblemen ist es meiner bescheidenen Erfahrung nach nicht wirklich hilfreich. Ich werde es aber trotzdem mal probieren.

Mein eigentliches Problem bleibt ja eigentlich aber dass die Torrents den Cache vollmachen. Ich hatte schon die Idee das ganze Torrentzeug in eine VM zu stecken in der Hoffnung dass der begrenzte der VM zugewiesene Speicher den Rest sauber hält. Aber zwei VMs verkraftet die Maschine nicht wirklich und außerdem erscheint mir das auch als mit Kanonen auf Spatzen geschossen. Lässt sich etwas ähnliches ohne Kanone, vielleicht mit einem chroot erzielen?

[Six]

Leider sind cgroups in Debian Squeeze aber quasi unbenutzbar. Die userspace tools sind buggy und wichtige Module (z. B. memory management) fehlen im stock 2.6.32er kernel völlig

Testweise hatte ich auf dem Rechner mal Kernel 3.2 aus den Backports installiert (wegen der zram-Geschichte aus dem anderen Thread) und irgendwann steht ja ohnehin das dist-upgrade an. Könnte mir das helfen? Über cgroups weiß ich leider nur das was vor ein paar Monaten prominent durch die Medien ging. Debianspezifisches weiß ich da gar nicht.

Da ging was prominent durch die Medien? Muss ich verpasst haben Jedenfalls sollten die 3.x alle cgroup Module mitbringen.

Die Quellen von Debian experimental sind anscheinend OK (Hörensagen, nicht selber ausprobiert!).

Hast du zufällig eine Link auf deine Hörensagen-Quelle?

Nö, sorry. Aber wie es scheint, ist libcgroup irgendwann im letzten Halbjahr in der aktuellen Fassung 0.38 in SID angekommen: http://packages.debian.org/sid/libcgroup1

[hupfdule]

Wenn das zu viel Aufwand ist, dann versuche es doch einfach mal mit nice. Erhöhe die Priorität der dir wichtigen Programme und der Kernel behandelt die direkt besser

Aber nice hilft doch nur bei CPU-Last soweit ich weiß. Bei I/O- und Loadproblemen ist es meiner bescheidenen Erfahrung nach nicht wirklich hilfreich.

Evtl. könnte dir da aber ionice aus dem util-linux Paket weiter helfen.

[hikaru]

Da ging was prominent durch die Medien? Muss ich verpasst haben Jedenfalls sollten die 3.x alle cgroup Module mitbringen.

Es gab um die Einführung von Kernel 3.0 eine Artikelserie auf Heise die sich (u.a.) mit cgroups beschäftigte.

Nö, sorry. Aber wie es scheint, ist libcgroup irgendwann im letzten Halbjahr in der aktuellen Fassung 0.38 in SID angekommen: http://packages.debian.org/sid/libcgroup1

Bis Wheezy ist die Version auch noch durchgerutscht.

Evtl. könnte dir da aber ionice aus dem util-linux Paket weiter helfen.

Danke! Das könnte zumindest einen Versuch wert sein.

[wanne]

Ich würde mir gern helfen lassen, nur leider scheinen deine theoretischen Überlegungen jeder praktischen Grundlage zu entbehren. Und das ist überhaupt nicht hilfreich.

Na du kanns entweder weiterhin behauptn, dass dein Rechner 10 Minuten braucht um nichtmal 5kiB in den RAm zu laden oder eben mal wie ich messen was tatsächlich passirt, wenn du den FF aufmachst. praktisch gemessene werte als theoretisches konstrukt zu bezichenen ist absolut doof...
Und ich habe bereits sinnvolle Lösungen gegeben. Und eben gezigt, was garantiert nicht funktioniert... (Ausschließlich die binary in den RAM zu laden.)
Und zu deinem ach so kleinen lxde der ist mit Abhängigkeiten etwa 200 mal so groß wie der Firefox.

[hikaru]

Evtl. könnte dir da aber ionice aus dem util-linux Paket weiter helfen.

Ich habe deluged (den Torrent-Client) über's Wochenende mal mit ionice idle laufen lassen, und siehe da, die Ladezeiten von Iceweasel und smplayer sind auf ca. 1/3 gesunken. Auf meinem anderen (als solches genutzten) Netbook geht das auch nicht viel schneller, für mich also ein brauchbares Ergebnis.

Danke!

[wanne]

Hatte ich ja schon 6 beiträge weiter vorne empfohlen...