Einsatz von nice beim Paketbau

H

holgerw

Guest
Hallo,

manchmal ist beim Einsatz von poudriere der PC etwas zähflüssig zu bedienen (Intel i5 CPU, 8 GB DDR3 Ram). Ein htop zeigt dann vor allem eine hohe CPU-Auslastung.

Nun kann ich ja mit
Code: 
nice -15 <programmname>
die Last reduzieren.

Wie ist das aber, wenn ich das nice auf poudriere loslasse? Wirkt sich das dann auch auf make u.s.f. aus, also, wird das weiter gereicht an die Folgeprozesse? Oder muss ich make direkt das nice verpassen?

Viele Grüße,
Holger
 
Hallo,

Auf Nice würde ich verzichten, denn dies müsste auf jeden Prozess angewendet werden.

/usr/local/etc/poudriere.conf
Code: 
116 # By default poudriere uses hw.ncpu to determine the number of builders.
117 # You can override this default by changing PARALLEL_JOBS here, or
118 # by specifying the -J flag to bulk/testport.
119 #
120 # Example to define PARALLEL_JOBS to one single job
121 # PARALLEL_JOBS=1
Du kannst hier mit dieser Einstellung die Anzahl der Jobs definieren. Vermutlich hast du einen Quadcore? Dann kannst du es mal mit "2" versuchen.

Gruss
 
Hallo @foxit

danke, dann werde ich das über die make.conf steuern. Und ja, ich habe einen Quad Core :)

Viele Grüße,
Holger
 
holgerw schrieb:
...Nun kann ich ja mit
Code: 
nice -15 <programmname>
die Last reduzieren.
...
Zum Vergrößern anklicken....

Das ist kompletter Unfug, denn man kann mit 'nice' und 'renice' keine "Last reduzieren" ... wer die Philosophie eines Time-Sharing-Multi-User-OS ansatzweise verstanden hat, kommt auch nicht auf solche Ideen.
 
Unter FreeBSD mit SCHED_ULE gibt 'nice' auch nur an, wie sehr sich die vom Scheduler ermittelte Priorität eines Threads über die Zeit verändert. Und das auch nur für Threads, die nicht 'interactive' klassifiziert sind. Der Einfluss ist daher in den meisten Situationen vernachlässigbar. Wesentlich wirksamer sind POSIX P1003.1B Realtime Priorities - unter FreeBSD in Form von rtprio(1) und idprio(1) - um simpel gesagt die Priorität eines Threads generell hoch- oder runterzudrücken. Man muss damit aber vorsichtig sein, dem Kernel zu sehr in seine Threadprioritäten zu pfuschen kann böse Nebenwirkungen bis hin zum Deadlock bzw. Crash haben. :)
 
Hallo,

danke für die Erklärungen. Am besten ist dann wohl doch, über die make.conf die Anzahl der zu verwendenden CPU-Kerne beim Paketbau zu reduzieren.

Das ist kompletter Unfug, denn man kann mit 'nice' und 'renice' keine "Last reduzieren" ... wer die Philosophie eines Time-Sharing-Multi-User-OS ansatzweise verstanden hat, kommt auch nicht auf solche Ideen.
Zum Vergrößern anklicken....

@Vril meinst Du, Beiträge, die einfach nur darauf zielen, Leute vorzuführen, ohne zu der Frage irgendetwas beizutragen, sind hier im Forum hilfreich? Mir ist klar, in Sachen Unix noch vieles lernen zu müssen, da passieren mir Schnitzer - aber Deine "superschlauen" Auslassungen, die meist nicht ohne persönliche Seitenhiebe auskommen und mit denen Du offenbar gar kein Wissen vermitteln willst, helfen mir nicht - und anderen sicherlich auch nicht.
 
Zuletzt bearbeitet von einem Moderator:
@Vril & @holgerw
es brennt mir unter den Nägeln und deshalb schreibe ich das mal hier, hätte es aber schon bei einigen anderen Threads tun können.
Offensichtlich ist Gift in eure Beziehung geflossen und zerstört nun eine normale Konversation.
So etwas sollte niemals passieren, nicht in einem öffentlichen Forum, wo es doch um Sachen geht und nicht darum, besser abzuschneiden oder Recht zu bekommen.
Wenn es doch mal passiert, kann es vielleicht helfen, wenn man darauf hinweist.
Mir sind Beiträge von euch beiden wichtig, aber wenn es nur darum geht, euch öffentlich gegenseitig an zu machen, dann kann ich darauf sehr gut verzichten.
Geht doch bitte in euch und verzichtet einfach darauf, antwortet einfach nicht. Wir können alle schon selbst sehen, was ein Beitrag taugt und was nicht.
Bitte entschärft eure Beiträge und entgiftet euer Verhältnis.

Und ich zögere, dies nun öffentlich zu machen und nicht zunächst per PM jeden einzeln an zu schreiben.
Ich nutze PM in einem Forum nur sehr ungern. Das widerspricht dem öffentlichen Charakter, das ist Geheimniskrämerei und nicht mit offenen Karten gespielt.
Ich will aber auch nicht ins OT abrutschen und etwa eine neue Diskussion hier entfachen.
Also bitte keine Antworten, gar keine.
Aber denkt mal nach. Es ist wirklich keine Bereicherung, euren Dauerzoff hier zu inszenieren.
 
zu nice.
Auch früher schon und mit Linux konnte ich nice nicht viel abgewinnen, außer mal eine Demonstration, was damit möglich ist. Für den Dauerbeitrieb nutzte ich es nie, nur mal ganz kurz, als ich früher noch Filme konvertierte und in platzsparende Codecs wandelte. Wenn ich ein halbes Dutzend Filme am Wandeln war und dann auch noch anfing Ports zu bauen oder einen Kernel zu kompilieren, dann konnte ich manchmal nicht mehr nebenher flüssig arbeiten und nutze dann von der Konsole schnell mal ein nice, um mir mehr Priorität gegenüber einem weniger wichtigen Prozess zu setzen.
Wirklich brauchbar ist so etwas nicht und eine Lösung schon gar nicht.
Für mich heißt die Lösung mehr HW oder weniger CPU-Last.
Mehr HW ist meist = mehr RAM und da stoße ich an mein altes Credo: ohne SWAP geht alles besser. Wer genug RAM hat, sollte mal versuchen, ohne SWAP zu arbeiten. Sobald ein System swapped, wird es lahm und es kann nur swappen (und wird das auch tun!), wenn SWAP vorhanden ist.
Weniger CPU-Last kann bedeuten, die Last zu verteilen: Ports baut man Nachts, wenn alles schläft und nicht, während man gleichzeitig seinen PC nutzen möchte! Einen Desktop Rechner würde ich nicht damit beschäftigen, hauptsächlich Ports zu bauen, gerade auch nicht mit poudriere. Hätte ich keine Wahl, dann wie gesagt, alles zu seiner Zeit und keinesfalls gleichzeitig.
 
Nach meiner Erfahrung liegt das nicht am Build selbst sondern am Intel-Grafik-Treiber wenn das System unter hoher Last träge wird. Minimiere das Terminal in dem der Build läuft, je nach Window-Manager sollte das helfen. Wenn Du tmux verwendest, wechsel in ein window in dem kein build läuft.

Es scheinen die vielen Buffer-Updates durch ein Terminal mit hoher Aktivität zu sein, die die Probleme verursachen. Selbst wenn man auf einem anderen Desktop unterwegs ist.
 
@foxit
habe Deinen Tipp probiert, allerdings statt der 2 dann doch 3 Builders zugelassen. Der Desktop ist trotz aktivem poudriere nun wieder flüssig und gut bedienbar.

Viele Grüße,
Holger
 
Kleine Anmerkung noch. Bei mir ist der Hauptgrund für ein langsames System bei den Builds der Zugriff auf die Festplatte. Da gibt's zwei Tricks:

Je nach RAM USE_TMPFS auf "yes" oder, wenn man mehr hat "wrkdir data" oder "all" stellen.

Wenn man nicht so viel RAM hat bzw. zusätzlich dazu kann man PREPARE_PARALLEL_JOBS auf 1 oder 2 stellen. Das sorgt dafür, dass nur ein oder zwei schreibintensives prepares gleichzeitig passieren. Nachdem die das ohnehin so schnell machen wie die können ändert das nichts an der Dauer und kann den Build im Extremfall sogar beschleunigen. Gerade auf Systemen ohne ZFS bringt das einiges.

EDIT: Und noch was. Wenn's wirklich die CPU ist könnte ein "sysctl kern.sched.preempt_thresh=220" (und in /etc/sysctl.conf eintragen) helfen, wenn es nicht ohnehin schon höher ist.

Das ist generell gut am Desktop.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben