Guter Artikel: Sehr lesbar und gegliedert geschrieben. Allerdings würde ich am Anfang auf rhetorische Fragen verzichten - ich meine dass dieser Stil veraltet ist (Es ist ja keine Rede und der Leser hat keine Chance zu antworten). Aber das ist sicherlich eine Ansichtssache.
Bisher hab ich cgroups und alles was damit zusamenhängt aus dem Kernel rausgelassen, weil hier eh nur 2 kerne und eine überschaubare Anzahl an Prozessen werkeln, oder entstehen dadurch irgendwelche nachteile auch für kleine Desktopmaschinen?
Spätestens wenn deine Distribution SysVinit/Upstart durch SystemD ersetzt brauchst du die grundlegende cgroups-Funktionalität im Kern (CONFIG_CGROUPS=y), da SystemD darauf angwiesen ist.
Die (im Artikel beschriebenen) Features, die cgroups mit sich bringen, stellt SystemD fürs Service- und Session-Management zur Verfügung. Hier ein Zitat aus Lennart Poetterings Blog:
You can use it for example to limit the total amount of memory or CPU Apache and all its children may use. Then, a misbehaving CGI script can no longer escape your setrlimit() resource control by simply forking away.
In addition to container and resource limit enforcement cgroups are very useful to keep track of daemons: cgroup membership is securely inherited by child processes, they cannot escape. There's a notification system available so that a supervisor process can be notified when a cgroup runs empty. You can find the cgroups of a process by reading /proc/$PID/cgroup. cgroups hence make a very good choice to keep track of processes for babysitting purposes.
Nein, nicht wirklich. Canonical hat einfach keinen echten Einfluss. Red Hat hat da schon anderes Gewicht. Ich denke das wir bald alle systemd nutzen. Das wird sich sicherlich wesentlich schneller durchsetzen, als es upstart bisher getan hat.
Wobei ich glaube, das "uns" auch schon mit upstart geholfen worden wäre.
Und um mein Lieblingsthema mit einzustreuen: Hauptsache systemd wird am Anfang weniger Stress machen als Pulseaudio
Ich hab irgendeinen Linuxguru Vortrag im Ohr, dass man wohl eine fork-Variation (fork2(), deamon(), was auch immer) plane, mit der man sich das nervige Doppelforken sparen kann, wenn man init den Prozess adoptieren lassen will.
Finde allerdings gerade nicht mehr wo das war, weiß jemand zufällig etwas darüber?
Von Freerunner_gast am Fr, 15. Oktober 2010 um 01:38 #
Ich nutze seit etwas über einem Jahr die BFS-, bzw. CK-Patches von Con Kolivas (http://ck.kolivas.org/patches/bfs/) und dieser Scheduler wirft die cgroups Funktionalität wieder aus dem Kernel raus.
Grund?
Unnötig für Desktop Systeme. Im allgemeinen finde ich CK's Ansatz, die Prozesse zu verteilen wesentlich sinnvoller als die ursprüngliche Implementierung. Naja, da mit Linux weniger auf dem Desktop Geld verdient wird, pumpen die Großen (RedHat & Co.) ihre Codebeiträge halt lieber in die Sektionen, wo es für sie am gewinnträchtigsten ist.
Wer einmal BFS ausprobiert hat, will nicht mehr zurück.
Im Beispiel werden keine Untergruppen erstellt. Nach der Darstellung:"CGroups Subsystem-Hierarchie" aus Seite 2 sollte das gehen - in der cgroups Beschreibung (http://www.mjmwired.net/kernel/Documentation/cgroups.txt) wird das auch geschrieben.
Nur funktioniert das bei mir nicht. Wurde das im Rahmen dieses Artikels getestet? Gibt es da etwas besonderes zu beachten?
untergruppen können nur erstellt werden wenn auch die genutzten subsysteme konfiguriert werden.
klassicher bedienfehler ist es das cpuset subsystem nicht zu konfigurieren - sofern cpuset genutzt/geladen wird. cpuset.mems und cpuset.cpus müssen hier zugewiesen werden ...
Ich bin mir ziemlich sicher das alle verfügbaren cgroup subsystems in der hierarchie geladen waren, und mindestens eins konfiguriert in der "test" gruppe noch konfiguriert werden muss damit eine sub-gruppe erstellt werden kann. Welches das sein kann weiss ich aus dem stehgreif nicht ...
... nach kurzem überfliegen vom kernel code hab ich evtl. doch ne ahnung. Das blkio cgroup subsystem in 2.6.34 untersützt keine hierachien die tiefer als 2 ebenen geht. Und ich geh jede wette eindas cgroup-vfs in deinem Fall ohne explitzt subsystem Auswahl geladen wurde und blkio somit mit in deiner cgroup hiearchie ist.
Versuch einfach mal ohne blkio subsystem eine cgroup hierachie zu mounten:
mount -tcgroup -ocpu,memory,cpuacct,cpuset,...allerlei..aber..kein...blkio... nodev /cgroup
Generell ist es nicht empfehlenswert die volle Breite von allen cgroup-subsystem zu laden. Immer nur die subsysteme in die hierachie laden die wirklich genutzt werden.
(Als der Artikel geschrieben wurde war blkio cgroup subsystem noch nicht gemerged im Vanilla Kernel.)
Guter Artikel: Sehr lesbar und gegliedert geschrieben. Allerdings würde ich am Anfang auf rhetorische Fragen verzichten - ich meine dass dieser Stil veraltet ist (Es ist ja keine Rede und der Leser hat keine Chance zu antworten). Aber das ist sicherlich eine Ansichtssache.
Warum ist dieser Stil veraltet? Rethorische Fragen sind was tolles. Ich arbeite selbst mit rethorischen Fragen, wenn ich mir ein paar Notizen mache.
Bisher hab ich cgroups und alles was damit zusamenhängt aus dem Kernel rausgelassen, weil hier eh nur 2 kerne und eine überschaubare Anzahl an Prozessen werkeln, oder entstehen dadurch irgendwelche nachteile auch für kleine Desktopmaschinen?
Spätestens wenn deine Distribution SysVinit/Upstart durch SystemD ersetzt brauchst du die grundlegende cgroups-Funktionalität im Kern (CONFIG_CGROUPS=y), da SystemD darauf angwiesen ist.
Die (im Artikel beschriebenen) Features, die cgroups mit sich bringen, stellt SystemD fürs Service- und Session-Management zur Verfügung. Hier ein Zitat aus Lennart Poetterings Blog:
"...durch SystemD"
Und wenn die Distrie systemd dann mit Upstart ersetzt, wieder nicht
Hältst du den Fall etwa für wahrscheinlich? Upstart kommt seit Jahren nicht in die Gänge. Leider, muss man sagen.
"Hältst du den Fall etwa für wahrscheinlich?"
Nein, nicht wirklich. Canonical hat einfach keinen echten Einfluss. Red Hat hat da schon anderes Gewicht. Ich denke das wir bald alle systemd nutzen. Das wird sich sicherlich wesentlich schneller durchsetzen, als es upstart bisher getan hat.
Wobei ich glaube, das "uns" auch schon mit upstart geholfen worden wäre.
Und um mein Lieblingsthema mit einzustreuen: Hauptsache systemd wird am Anfang weniger Stress machen als Pulseaudio
Ich hab irgendeinen Linuxguru Vortrag im Ohr, dass man wohl eine fork-Variation (fork2(), deamon(), was auch immer) plane, mit der man sich das nervige Doppelforken sparen kann, wenn man init den Prozess adoptieren lassen will.
Finde allerdings gerade nicht mehr wo das war, weiß jemand zufällig etwas darüber?
Ich nutze seit etwas über einem Jahr die BFS-, bzw. CK-Patches von Con Kolivas (http://ck.kolivas.org/patches/bfs/) und dieser Scheduler wirft die cgroups Funktionalität wieder aus dem Kernel raus.
Grund?
Unnötig für Desktop Systeme. Im allgemeinen finde ich CK's Ansatz, die Prozesse zu verteilen wesentlich sinnvoller als die ursprüngliche Implementierung. Naja, da mit Linux weniger auf dem Desktop Geld verdient wird, pumpen die Großen (RedHat & Co.) ihre Codebeiträge halt lieber in die Sektionen, wo es für sie am gewinnträchtigsten ist.
Wer einmal BFS ausprobiert hat, will nicht mehr zurück.
Danke! BFS kling richitg spannend, habe mir gerade die FAQ durchgelesen. Wohlan, ich habe den BFS patch, alleine, wie spiele ich ihn ein?
Ich habe nie wirklich -p0, -p1 verstanden, daher hilft mir man patch nicht weiter.
Wenn Du im Verzeichnis mit den Kernelquellen bist, einfach "patch -p1 < [Name des Patches]" eintippen. Der Patch wird dann angebracht.
Danach ganz gemütlich den Kernel konfigurieren, Kernelfrequenz auf 1000 Ticks stellen und kompilieren.
Etwaige Unterschritte erfährst Du in der Dokumentation Deiner Distro.
Danke. Wenn der Patch jetzt aber nicht unter /usr/src/linux sondern direkt unter /usr/src stünde, würde ich dann patch -p0 nehmen?
Blöde Frage, ziehe ich zurück. Der Patchbefehl muß unter /usr/src/linux ausgeführt werden, wo die Patchdatei liegt, ist dabei egal
Im Beispiel werden keine Untergruppen erstellt.
Nach der Darstellung:"CGroups Subsystem-Hierarchie" aus Seite 2 sollte das gehen - in der cgroups Beschreibung (http://www.mjmwired.net/kernel/Documentation/cgroups.txt) wird das auch geschrieben.
Nur funktioniert das bei mir nicht. Wurde das im Rahmen dieses Artikels getestet?
Gibt es da etwas besonderes zu beachten?
untergruppen können nur erstellt werden wenn auch die genutzten subsysteme konfiguriert werden.
klassicher bedienfehler ist es das cpuset subsystem nicht zu konfigurieren - sofern cpuset genutzt/geladen wird. cpuset.mems und cpuset.cpus müssen hier zugewiesen werden ...
Ich hab das mal erneut getestet:
# mkdir test
# cd test
# echo 0 > cpuset.mems
# echo 0 > cpuset.cpus
# cat memory.use_hierarchy
1
# mkdir subtest
mkdir: cannot create directory `subtest': Invalid argument
es geht also auch mit den CPU Sets nicht.
Vielleicht liegt es am Fedora Kernel?
Der ist aktuell: 2.6.34.7-61.fc13.i686
Glaube nicht das es am Kernel liegt.
Welche subsysteme werden den alle geladen? alle?
Evtl. eingrenzen und nur zum Beispiel die "gewünschten" subsysteme laden. Ohne mount option und explitzite Auswahl werden alle subsysteme geladen.
Beispiel - nur cpu und cpuset subsystem in hierachie laden:
# mount -tcgroup -o cpu,cpuset nodev /cgroup
# mkdir /cgroup/test
# mkdir /cgroup/test/subtest
# wc -l /cgroup/test/subtest/tasks
0 /cgroup/test/subtest/tasks
# echo 0 > /cgroup/test/
# echo 0 > /cgroup/test/cpuset.mems
# echo 0 > /cgroup/test/cpuset.cpus
Ich bin mir ziemlich sicher das alle verfügbaren cgroup subsystems in der hierarchie geladen waren, und mindestens eins konfiguriert in der "test" gruppe noch konfiguriert werden muss damit eine sub-gruppe erstellt werden kann. Welches das sein kann weiss ich aus dem stehgreif nicht ...
... nach kurzem überfliegen vom kernel code hab ich evtl. doch ne ahnung. Das blkio cgroup subsystem in 2.6.34 untersützt keine hierachien die tiefer als 2 ebenen geht. Und ich geh jede wette eindas cgroup-vfs in deinem Fall ohne explitzt subsystem Auswahl geladen wurde und blkio somit mit in deiner cgroup hiearchie ist.
./block/blk-cgroup.c
----8top_cgroup)
return ERR_PTR(-EINVAL);
[...]
--->8----
Versuch einfach mal ohne blkio subsystem eine cgroup hierachie zu mounten:
mount -tcgroup -ocpu,memory,cpuacct,cpuset,...allerlei..aber..kein...blkio... nodev /cgroup
Generell ist es nicht empfehlenswert die volle Breite von allen cgroup-subsystem zu laden. Immer nur die subsysteme in die hierachie laden die wirklich genutzt werden.
(Als der Artikel geschrieben wurde war blkio cgroup subsystem noch nicht gemerged im Vanilla Kernel.)
mfg
Daniel
Super.
Danke, daran lag es. Problem gelöst.