1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

Einsatz von nice beim Paketbau

Dieses Thema im Forum "FreeBSD - Allgemein" wurde erstellt von holgerw, 16 März 2017.

  1. holgerw

    holgerw Active Member

    Registriert seit:
    29 Februar 2016
    Beiträge:
    739
    Ort:
    Simtshausen - Hessen
    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
     
  2. foxit

    foxit Moderator Mitarbeiter

    Registriert seit:
    4 Juli 2012
    Beiträge:
    1.294
    Ort:
    /home
    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
     
    holgerw gefällt das.
  3. holgerw

    holgerw Active Member

    Registriert seit:
    29 Februar 2016
    Beiträge:
    739
    Ort:
    Simtshausen - Hessen
    Hallo @foxit

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

    Viele Grüße,
    Holger
     
  4. Vril

    Vril Member

    Registriert seit:
    4 August 2016
    Beiträge:
    101
    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.
     
  5. lme

    lme FreeBSD Committer

    Registriert seit:
    6 Mai 2003
    Beiträge:
    2.552
    Ort:
    Düsseldorf
    Man kann aber auch "renice -20 -u meinuser" ausführen, dann ist meinuser was Besseres als die anderen ;)
     
    holgerw gefällt das.
  6. Yamagi

    Yamagi Possessed With Psi Powers Mitarbeiter

    Registriert seit:
    14 April 2004
    Beiträge:
    8.550
    Ort:
    Schleswig-Holstein
    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. :)
     
    holgerw gefällt das.
  7. holgerw

    holgerw Active Member

    Registriert seit:
    29 Februar 2016
    Beiträge:
    739
    Ort:
    Simtshausen - Hessen
    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.

    @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: 16 März 2017
  8. pit234a

    pit234a Well-Known Member

    Registriert seit:
    8 Juli 2006
    Beiträge:
    2.700
    @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.
     
  9. pit234a

    pit234a Well-Known Member

    Registriert seit:
    8 Juli 2006
    Beiträge:
    2.700
    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.
     
  10. Kamikaze

    Kamikaze Bottom Poster Mitarbeiter

    Registriert seit:
    26 Mai 2005
    Beiträge:
    10.823
    Ort:
    /Earth/Europe/Germany/Karlsruhe
    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.
     
    holgerw gefällt das.
  11. holgerw

    holgerw Active Member

    Registriert seit:
    29 Februar 2016
    Beiträge:
    739
    Ort:
    Simtshausen - Hessen
    @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
     
  12. Athaba

    Athaba Libellenliebhaber Mitarbeiter

    Registriert seit:
    10 März 2005
    Beiträge:
    3.219
    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.
     
    holgerw gefällt das.