Aufwand eines zu installierenden Ports

vlast

vlast

Well-Known Member
Hallo.

Weder das Forum noch Google konnten mir in meinem Belangen weiterhelfen.

Gibt es irgendeine Möglichkeit, im Vorraus oder während der Installation, eines Ports seine abschließende Größe oder die ungefähre Dauer seiner Kompilation zu prüfen?

Oder kann man das lediglich anhand von Erfahrung oder Abschätzung der letztlichen Applikationen (bspw. nano vs. KDE) ausmachen?

Würde mich schon manchmal interessieren, ob es sich lohnt, vor dem PC sitzen zu bleiben oder ob man zwischenzeitlich was anderes machen kann!

MfG
 
Du kannst dir nur die Abhängigkeiten, die zu installieren, z. B. bei portmaster anzeigen lassen. Wie lange das dauert, kann man nie so genau sagen. Aber es spricht ja auch nichts dagegen in der Zeit einfach den Computer weiterhin zu verwenden, wenn die Kiste nicht allzu alt ist.
 
Bestimmte Build-Systeme haben Progress Anzeige, zB cmake und dieses Python-basierte, das auch Chromium verwendet. Ansonsten kann man nicht wissen, wie lange es dauert.
 
Nicht ganz zum Thema passend, aber evtl. weiß ja jemand ne Antwort dazu.

Code: 
===>>> Delete TeX/texlive-20140525-texmf.tar.xz? y/n [n]

Wie kann ich sowas automatisiert übergehen, damit das Bauen nicht stehenbleibt und auf Antwort wartet?
 
Die Meldung kommt von portmaster, oder? Einfach mit "-d" für "delete" starten.
 
Ah, vielen Dank!

War mir nicht bewusst, dass das von portmaster kommt. :)

Gibt es denn bei Portmaster auch einen Schalter, dass er die Defaults von den Ports übernimmt, wenn man viele auf einmal baut? Oder ich habs in der manpage überlesen. :S
 
ja in der /usr/local/etc/portmaster.conf (oder wie die heisst - hab gerade kein system hier). Dort einfach mal suchen. Es gibt dort die Option "Always scrub distfiles" oder so. Einfach die dortige Option (-d ?) entkommentieren und die Frage kommt nie wieder ;)
 
Das wär ja noch geiler. :)

Was ist denn ein distfile genau? Einfach die alte Version in eine tar-gz gepackt zu Backupzwecken?
 
Eigentlich sind die distfiles die Quellcode Archive aus denen dann das fertige Paket mittels des FreeBSD Ports Systems gebaut wird. Öfter mal kommen neue Patches im FreeBSD Ports System hinzu, während das ursprüngliche distfile weiter genutzt werden kann. Löscht man immer alle distfiles müssen die distfiles immer wieder von den Download Servern der Projekt Seiten heruntergeladen werden. Das Budget der OpenSource Projekte lässt sich durch aufheben und weiter verwenden der heruntergeladenen distfiles sicher schonen. Der bessere Weg ist wohl nur veraltetete distfiles zu löschen.
Bei portupgrade gibt es dafür das Werkzeug portslean mit dem Schalter -D:
Code: 
portsclean -D
 
Kann man übrigens auch im laufenden Betrieb die Priorität vom Bauvorgang runterschrauben oder macht man das in der make.conf mit -o3, wenn man z.B. 4 Kerne hat?
 
Ich würde nicht wirklich was optimieren in der make.conf... Nachher läuft irgendein Port nicht und man weiß nicht, wo der Fehler liegt...

Und das mit den Prioritäten erledigt das Betriebssystem für dich :D Aber du möchtest vermutlich einstellen können, dass nur 20% der Leistung genutzt wird, damit der Rest des Systems ordentlich läuft. Das geht einfach so nicht wirklich... Aber ich finde, es lässt sich noch ziemlich angenehm surfen und so, wenn im Hintergrund ein paar Ports gebaut werden.
 
Prozesse wie cc und c++ haben einen hohen Nice-Wert, was dafür sorgt, dass alles Andere Priorität hat. Wenn jedoch Rechenkapazitäten frei sind werden die auch genutzt.
 
Aber du möchtest vermutlich einstellen können, dass nur 20% der Leistung genutzt wird, damit der Rest des Systems ordentlich läuft. Das geht einfach so nicht wirklich... Aber ich finde, es lässt sich noch ziemlich angenehm surfen und so, wenn im Hintergrund ein paar Ports gebaut werden.
Zum Vergrößern anklicken....

Exakt das. :) Surfen ist kein Thema, aber wenn ich mit VLC einen Film laufen lasse, dann krieg ich diese bekannten Bildfehler dabei.

@Kamikaze

Kommt da nicht so hin bei VLC ;) Oder kann man den anderen Weg gehen, einfach VLC dann mehr Prio geben?
 
Eine alte Weisheit zum Thema Scheduling lautet, dass man es nur falsch machen kann. Egal welchen Algorithmus man benutzt, egal welche Entscheidungen man trifft, es gibt immer Szenarien welche benachteiligt werden. Für FreeBSDs ULE Scheduler waren schon immer sehr kurz laufende, viel Rechenleistung ziehende Prozesse tendenziell tödlich. Eben wie Compiler. Das ist der Grund, weshalb ich auf Desktops auch Intels Core i7 mit SMT (aka Hyperthreading) den kastrierten Core i5 vorziehe. Man gibt die harten Kerne den aufwendigen Prozessen, wie den Compilern, und daddelt selbst auf den virtuellen Kernen herum.

Aber zum Thema. Die Anzahl der parallel laufenden Compiler kannst du in der /etc/make.conf begrenzen:
Code: 
MAKE_JOBS_NUMBER_LIMIT=N
N ist logischerweise die maximale Anzahl an Jobs.
 
Wie kann man das steuern, dass nur die Kerne benutzt werden? Ist beim AMD ja eh hinfällig, weil kein HT, aber rein aus Interesse. :)
Ich gondel ja schon seit geraumer Zeit mit alter Hardware rum, da die Gam0r-Zeit und das dauernde Nachrüsten beendet ist. Außerdem habe ich gemerkt, dass ich mit verschiedenen Rechnern auf einmal besser fahre.
Um mal eine zeitliche Orientierung zu bekommen....wie lange dauert denn das Compilen auf so einem aktuellen i7 Kraftprotz? Hast du da was als Vergleichswert? KDE4 oder libreoffice? Auf dem E350 hat libreoffice so 10-12 Stunden gebraucht, habe nicht genau gemessen. :)

Also dann probier ich N mal mit 'Anzahl der Kerne-1'. Prozentual gibts da nix? Einem Prozess 'IDLE' zuweisen war unter Windows genau das Ding, was ich hierfür suche.
 
Also, FreeBSD nutzt automatisch die physischen Kerne mit höherer Priorität als die virtuellen Kerne. Daher muss man sich normalerweise um nichts kümmern. Wenn man denn trotzdem manuell eingriffen will oder muss, ist cpuset(8) das Mittel der Wahl. Damit kann man Prozesse und Prozesshierarchien an Prozessoren binden. Prozentual gibt es auf der Ebene ebenfalls nichts, da du nur festlegst, wie viele Prozesse make(1) aufruft. Wenn du es granularer begrenzen möchtest, ist rctl(8) dein Freund. Aber das Ding ist in vielen Fällen schlicht Overkill.

Die Leistung zu schätzen ist immer schwer. Nehmen wir mal "make buildworld". Mein guter, alter Phenom II 940 (4 Kerne, 3.2GHz) brauchte knappe 45 Minuten. Der Core i7 2600k (4 Kerne, 3.4GHz, SMT) ist durch die im Vergleich höhere Effizient ziemlich genau doppelt so schnell und baut es in gut 20 Minuten. Ein dicker Server mit 2x Xeon E5-2630 (12 Kerne, 2.6GHz, SMT) schafft es in etwa 5 Minuten und dort bremst bereits die SSD. Sehr grob über den Daumen kann man sagen, dass unter Volllast und bei perfekter Parallelisierung eine CPU mit SMT (Core i7) etwa 130% der Leistung einer CPU ohne SMT (also Core i5) bringt. Wenn man also vor allem rechnen möchte, lohnt sich der gar nicht mal so hohe Aufpreis durchaus.
 
Sehr gute Ausführung, danke!

Wichtig ist vor allem aber, dass alles am Ende wie gewünscht funktioniert...da spielt die Zeit weniger die Rolle. :)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben