cvsup & Co. sehr langsam

A

Aleister

Well-Known Member
Hallo,

es betrifft nicht unbedingt nur cvsup, sondern ich lass per Script
die Ports per cvsup abgleichen und danach erfolgt ein
portsdb -Uu
pkgdb -F
portversion -l "<"

Bei meiner Workstation Athlon XP 2400 mit 512MB dauert das ca. 30 Minuten. Bei meinem Notebook einem älteren Toshiba mit k6-2 366 MHZ und 160 MB RAM und einer 4200 upm drehenden Platte dauert der Vorgang ca. 3-4 Stunden. Ist das für diese Hardware normal?

Der cvsup Vorgang dauert gar nicht mal so lange. Was richtig lange dauert ist portdb -Uu. Was allerdings an einem Index aufstellen so lange dauern kann, um herauszufinden, welche Ports erneuert werden müssen, entzieht sich meiner Fantasie.

Vergleiche ich das mit sync von Gentoo der von cvsup bis portversion -l beinhaltet oder der Debian-Methode apt-get update gefolgt mit einem apt-get -s upgrade, so geht das dort ruckzuck.

Muss ich irgendwo Einstellungen machen oder muss ich mit dieser Geschwindigkeit leben.
 
Hmmm.
Ja, portsdb -Uu braucht wirklich etwas lange um den Index aufzubauen.
Aber der Reihe nach.
"make index" und "portsdb -U" machen einen update von INDEX. INDEX wird von den Base system utilities genutzt die mit den Ports arbeiten (pkg_info beispielsweise).

Nun greift "pkg_version" oder "make search" auf die Datei INDEX zu.
ABER, "pkg_version" vergleicht den installierten Port mit dem Port der im Portstree steckt, dafür braucht es die Datei INDEX erstmal nicht. Diese braucht es nur, wenn der Port nicht mehr existiert (gelöscht, in eine andere Kategorie verschoben).
Summa sumarum, eine Datei INDEX muss nicht up-to-date sein. Daraus wiederum schliessen wir, das ein "portsdb -U" oder "make index" nicht unbedingt notwendig ist.

Dann ist da die INDEX.db, diese ist von "portupgrade" und wird von "portversion" genutzt.
Gebaut wird dies wiederum mit "portsdb -u" (vergleiche hierzu die manpage zu portsdb).

Schlussendlich kannst Du Dir das "-U" beim portsdb sparen, und nur "-u" angeben.
Ein einmal wöchentliches "portsdb -uU" sollte ausreichen, oder einmal im Monat....
 
Original geschrieben von asg
Schlussendlich kannst Du Dir das "-U" beim portsdb sparen, und nur "-u" angeben.
Ein einmal wöchentliches "portsdb -uU" sollte ausreichen, oder einmal im Monat....
Zum Vergrößern anklicken....

Also in allen Dokus die ich dazu gelesen habe, wird überall das portsdb -Uu aufgeführt. Gerade um den Index korrekt aufzubauen. Gut man kann das ja mal ausprobieren nächste Woche.

Jedoch ist mir noch nicht schlüssig was diesen Prozess mehrere Stunden beschäftigt. Ich habe ja die Festplattenperformance im Auge denn eine Notebookplatte ist nicht wirklich schnell. Allerdings wenn ich manche Dokus lese wird auch immer darauf hingewiesen das portsdb -Uu "sehr" lange dauert.

Von der Anzahl der Informationen könnte man FreeBSD mit Debian gleichsetzen, dort sind auch ca. 10.000 Paketinformationen im Stable-Zweig vorhanden, also fast identisch mit dem aktuellen Stand der Ports. Was dauert da so lange um diesen Index zu erstellen?

Gibts denn noch eine Möglichkeit wo ich "schrauben" kann? Wäre interessant zu wissen wenn jemand mit vergleichbarer Hardware mal mitteilen könnte wie lange das bei ihm dauert um mal Vergleichswerte zu haben.

Wenn nicht, muss man halt damit leben.
 
Hmmm.
Ich dachte das es mal so gewesen ist wie ich oben geschrieben habe.
Hab eben den source überflogen von den portupgrade Utilities, und bin nun der Meinung das INDEX auch von portversion genutzt wird, und daraus auch die INDEX.db erstellt wird.
Muss mir das nochmal in Ruhe ansehen...

Ahh, da hat er schon geschrieben....

Du kannst ja mal "make index" aufrufen unter /usr/ports, ist ja wie "portsdb -U" und zuschauen was er macht....
 
Was dauert da so lange um diesen Index zu erstellen?
Zum Vergrößern anklicken....
Das ist ein Prozess, der sich aus dem Aufruf einiger Tausend 'make' bzw. Shellscripts zusammensetzt. Schau dir mal bei 'top' die 'last pid:' Ausgabe an, das rotiert typischerweise einmal durch, startet also mehr als 100.000 Prozesse. Das dauert halt...

Ich weiss ja nicht, welche Motivation Du hast, dauernd Deine Ports upzudaten, aber ich würde sagen einmal alle zwei bis vier Wochen genügt. Und dann sind 3h doch nicht mal sooo lang.
 
Original geschrieben von asg
Du kannst ja mal "make index" aufrufen unter /usr/ports, ist ja wie "portsdb -U" und zuschauen was er macht....
Zum Vergrößern anklicken....

Was er macht ist gut:
Generating INDEX - please wait..

Hab ich gemacht und die Zeit notiert. Mal sehen wie lange es braucht, dann kann wenigstens dazu eine genauere Aussage mitteilen. Ansonsten läuft da nichts was nicht laufen sollte. Bin sogar per ssh auf dem Notebook eingeloggt, X läuft auch nicht. Aber wenn ich mir Top anschaue ist das auch kein Problem vom Hauptspeicher.
 
Original geschrieben von current
Das ist ein Prozess, der sich aus dem Aufruf einiger Tausend 'make' bzw. Shellscripts zusammensetzt. Schau dir mal bei 'top' die 'last pid:' Ausgabe an, das rotiert typischerweise einmal durch, startet also mehr als 100.000 Prozesse. Das dauert halt...
Zum Vergrößern anklicken....

Das ist schon einleuchtend. Jedoch wie bereits geschrieben, warum das mehere Stunden dauert entzieht sich mir. Zwei Alternativsysteme aus dem Linux-Sektor hatte ich ja aufgeführt.

Ich weiss ja nicht, welche Motivation Du hast, dauernd Deine Ports upzudaten, aber ich würde sagen einmal alle zwei bis vier Wochen genügt. Und dann sind 3h doch nicht mal sooo lang.
Zum Vergrößern anklicken....

Hab ich behauptet andauernd oder täglich meine Ports upzudaten?
Es ist ca. 10-14 Tage her. Aufgefallen ist mir das schon öfter das das so lange dauert. 3 Stunden sind natürlich nicht so lang, allerdings wenn gleiche Updatetechniken dafür 1-2 Minuten brauchen oder weniger, dann sollte man das doch schon mal hinterfragen.
 
Jedoch wie bereits geschrieben, warum das mehere Stunden dauert
entzieht sich mir.
Zum Vergrößern anklicken....
Vermutlich im wesentlichen deshalb, weil

1. Der bestehende Mechanismus zwar langsam ist, aber funktioniert
2. Sich noch niemand gefunden hat, eine bessere Implementation zu schreiben

Wenn Du Zeit und Lust hast, Punkt 2. anzugehen, ist dir ein Eintrag in der Contributors Liste sicher :)
 
fastest_cvsup

wenn dir das cvsup noch zu langsam gehen sollte könntest
du fastest_cvsup vorschieben /usr/ports/ports/sysutils/

#!/bin/sh
if SERVER=`fastest_cvsup -q -c de`; then
/usr/local/bin/cvsup -g -L 2 -h $SERVER /etc/cvsup/ports-supfile
fi

Funktioniert nicht schlecht
Attila
 
Re: fastest_cvsup

Original geschrieben von attila
wenn dir das cvsup noch zu langsam gehen sollte könntest
du fastest_cvsup vorschieben /usr/ports/ports/sysutils/
Zum Vergrößern anklicken....

Kenn ich, hab ich auch vorgeschaltet. Aber wie bereits in meinem Ursprungsposting mitgeteilt, hat es mit cvsup eigentlich nichts zu tun, sondern mit der Erstellung des Indexes nach dem cvsup Lauf.
 
Original geschrieben von current

1. Der bestehende Mechanismus zwar langsam ist, aber funktioniert
2. Sich noch niemand gefunden hat, eine bessere Implementation zu schreiben
Zum Vergrößern anklicken....

1) Das ist natürlich einleuchtend. Das das ganze Portssystem ein schneller Hack war ist ja bekannt, warum aber da nichts geändert wurde oder mal bei den Kollegen von z.B. Gentoo vorbeigeschaut wurde.

Zu 2) wie eben schon kurz angedeutet es gibt ja Verfahren da bräuchte man m.E. nicht viel neu coden. Leider bin ich kein Programmierer.
 
Ok, wird Zeit das mal jemand portupgrade auf die Sprünge hilft und davor die INDEX Datei etwas trimmt....
Programmierer immer nach vorne...
 
Original geschrieben von asg
Ok, wird Zeit das mal jemand portupgrade auf die Sprünge hilft und davor die INDEX Datei etwas trimmt....
Zum Vergrößern anklicken....

Auf Portupgrade will ich das gar nicht schieben, denn das bedient sich doch nur der vorhandenen Mechanismen. Klar ist auch meine in diesem Fall ältere Hardware vor allem mit einer langsamen Festplatte zu berücksichtigen Bj 99. Auf einem schnellen System geht das ganze natürlich viel zügiger allerdings auch nicht wie andere Updatemechanismen.

Erschreckend fand ich gerade beim googeln zu diesem Thema eine Nachricht von Jordan Hubbard selber zu diesem Thema. Diese News wurde am 27. Feb 02 also vor fast 2 Jahren (!) auf Pro-Linux veröffentlicht. Scheint so als wenn hier wieder das Kathedralenprinzip zuschlägt.

http://www.pro-linux.de/news/2002/4033.html
 
Ja, er findet auch das sysinstall, auch ein schneller böser Hack, endlich mal erneuert werden sollte...
Muss sich nur jemand finden, das ist das Problem. Ich würde da gerne dran arbeiten, bin aber beileibe kein Programmierer der das könnte, bin eigentlich gar kein Programmierer ;-).

Je mehr Ports es werden, umso langsamer wird dieses System natürlich. Ja, damals gab es einfach noch nicht knapp 10.000 Ports.
 
@Aleister: Das ganze Paketsystem unter FBSD ist relativ ineffizient. portsdb -U startet dir ein paar hunderttausend Prozesse, ruby, make, shs und was es noch alles startet. Das dauert leider sehr lange.

Meiner Meinung nach müßte das dringend überholt werden. AFAIk wurde soetwas wie "Ports2" auch initiiert, fanden sich nur nicht genügend unterstützende Entwickler.

Tatsache ist leider - und mir werden hier sicherlich wiedersprechen - das Debian und Gentoo zumindest in Teilbereichen das Ports-System deutlich überholt haben und es nicht mehr das Pro-Argument für FBSD ist, das es einmal war.

Selbst zu gucken, welche Uphängigkeiten ein Paket nicht erfüllt oder was installiert werden muß, damit sie erfüllt sind, ist nicht ganz einfach. Davon abgeshen frage ich mich, wer pretty-print-run-depends-list und pretty-print-build-depends-list eingeführt hat, länger ging's wohl nicht?
 
Original geschrieben von cirad
@Aleister: Das ganze Paketsystem unter FBSD ist relativ ineffizient. portsdb -U startet dir ein paar hunderttausend Prozesse...
Zum Vergrößern anklicken....

Stimmt wie ich mir das notierte waren es ca. 150.000 (!) sowas nennt man effizient

Meiner Meinung nach müßte das dringend überholt werden. AFAIk wurde soetwas wie "Ports2" auch initiiert, fanden sich nur nicht genügend unterstützende Entwickler.
Zum Vergrößern anklicken....

Meine Rede. Die Zahlen die ich neulich irgendwo las waren ca. 300 Entwickler im BSD Sektor. Da hat selbst Debian ein vielfaches von. Ich schätze mal das Gentoo mittlerweile auch schon mehr Entwickler hat trotz des kurzen Existenszeitraumes (Spekulation I). Wie auch schon zum Thema Lizenz von mir erwähnt, bin ich der Meinung das die GPL für viele Entwickler, und das sagen die auch eindeutig, interessanter ist als die BSD Lizenz (Spekulation II)

Tatsache ist leider - und mir werden hier sicherlich wiedersprechen - das Debian und Gentoo zumindest in Teilbereichen das Ports-System deutlich überholt haben und es nicht mehr das Pro-Argument für FBSD ist, das es einmal war.
Zum Vergrößern anklicken....

Ich widerspreche Dir nicht, aber dafür werden schon andere sorgen :-)

Full ACK, genau so sehe ich es auch. Das Portssystem war immer eine Werbung für die BSD´s weil das einzige effiziente Paketsystem zum damaligen Zeitpunkt das von Debian war. Mit der Einführung von Gentoo ist das obsolet. Man sollte schon bereit sein über die Tellerränder zu schauen um sowas zu bemerken und dann evtl selbst einzubauen.
 
@Aleister
Ich weiss nicht wo du die Zahl von 300 BSD Entwicklern her hast. Tatsache ist jedenfalls, dass allein FreeBSD rund 300 Committer hat. Das sind aber nur Leute, die einen formalen Status als Entwickler mit Schreibrecht fuer den Sourcetree haben. Wer ist Entwickler eines Projekts? Derjenige, der substanzielle Beitraege zur Weiterentwicklung des Kernels macht, derjenige, der Ports oder Pakete liefert oder derjenige der einen Tippfehler in der Dokumentation korrigiert?

Was die Lizenz angeht, so glaube ich nicht, dass der Erfolg von Linux irgendetwas mit der GPL zu tun hat. Es ist sicher entscheidend, dass es eine Lizenz fuer freie Software ist, aber es duerfte ziemlich egal sein ob es sich dabei um eine copyleft Lizenz handelt oder um eine nicht-copyleft Lizenz. Ich denke die Erfolgsfaktoren von Linux sind andere: z.B. glueckliches Timing, relative Homogenitaet der Entwicklerguppe am Anfang des Projekts, Luecken fuer kommerzielle Elemente im Entwicklungsmodell, Medienkompatibilitaet.
Andere prominente Projekte der Open Source Szene stehen unter einer BSD-artigen Lizenz und sind in ihrem Bereich noch sehr viel erfolgreicher als Linux, man denke etwa an den Webserver Apache. Solche Projekte koennen eine Eigendynamik entwickeln, die weitgehend abgekoppelt ist von der tatsaechlich vorhandenen technischen Qualitaet des Produkts. Konkurrierende Projekte werden so ins Abseits gedraengt.
 
Original geschrieben von Aleister
Meine Rede. Die Zahlen die ich neulich irgendwo las waren ca. 300 Entwickler im BSD Sektor.
Zum Vergrößern anklicken....

<ironie>
Viele Köcher verderben den Brei
</ironie>

Was ist damit gemeint? Die die Schreibrechte haben auf den Tree? Oder all die die etwas dazu beisteuern?

Da hat selbst Debian ein vielfaches von. Ich schätze mal das Gentoo mittlerweile auch schon mehr Entwickler hat trotz des kurzen Existenszeitraumes (Spekulation I).
Zum Vergrößern anklicken....

Wieviel Entwickler dürfen denn bei Debian und Gentoo auf den Tree schreiben? Ansonsten siehe <ironie>.
Bitte Fakten, keine Spekulationen, insbesondere keine bei denen das Ende der Spekulation und Dein Ansinnen nicht zu erkennen ist.

Wie auch schon zum Thema Lizenz von mir erwähnt, bin ich der Meinung das die GPL für viele Entwickler, und das sagen die auch eindeutig, interessanter ist als die BSD Lizenz (Spekulation II)
Zum Vergrößern anklicken....

Wieder die Lizenz...
Hatten wir das nicht schon?
Leider kan in dem Thread, welcher immer das war, nicht mehr Deinerseits. Und ich hatte damals schon etwas zu geschrieben.
Ich frage mich nur, warum setzt Du FreeBSD ein, wenn Dir die Lizenz stinkt, das Portsystem oll ist und es bei anderen Projekten mehr Entwickler gibt...
Was macht es für Dich dann zum System der Wahl?
 
@asg: Die Frage war zwar nicht an mich gestellt, aber ich antworte trotzdem mal darauf. (:

# Ich frage mich nur, warum setzt Du FreeBSD ein, wenn Dir die Lizenz stinkt, das Portsystem oll ist
# und es bei anderen Projekten mehr Entwickler gibt... Was macht es für Dich dann zum System der Wahl?

1) Die BSD-Lizenz ist ungeeignet. Die BSD-Lizenz ist geeignet. Die GPL ist ungeeignet. Die GPL ist geeignet. Kommt drauf an, was man will. (: Schade ist auf jeden Fall, daß Linux von BSD Sachen übernehmen kann, umgekehrt die GPL im Weg steht.

2) Ich habe hier ja ebenfalls geschrieben, daß ich die Ports nicht wirklich berauschend finde. Sie sind brauchbar, aber nicht unbedingt so herausragend, daß man sie besonders hervorheben müßte.

3) Die Anzahl der Entwickler ist mir persönlich relativ egal. Wieviel ein Entwickler in welcher Zeit schafft und wieviel Zeit er investiert, ist für mich nicht ersichtlich, auch wenn es immer heißt, daß die BSD-Entwickler etwas weniger Freizeit für BSD investieren als das bei beispielsweise vielen Linux-Entwicklern der Fall ist (Dillon sprach davon erst neulich im "IRC-Interview"). Recht eindeutig ist außerdem, daß Linux einem stärkeren Hype unterliegt und entsprechend viele Unternehmen darauf anspringen und Code beisteuern. In einem Maße, den man bei FBSD nicht findet. Aber wie gesagt, das interessiert mich eigentlich wenig.

4) Warum trotzdem FBSD, obwohl ich die Ports eher mittelmäßig finde? Übrigens wird bei FBSD 5.x bei mir auch der Sound bei hohem Platten-IO ziemlich verzerrt, XMMS braucht 10% CPU-Zeit (unter Linux nur ein ca. 1/50 davon, was schon enorm ist), das gleiche gilt für MPlayer/Xine/ogg123/mpg123/mpg321, mir konnte bisher niemand eine Möglichkeit nennen, wie ich unter FBSD Platten runterfahre, etliche Software wie Realplayer oder Acroread muß "emuliert" werden, Mozilla Nightly Builds gibt es nicht für FBSD und so weiter. Mich stört auch ein wenig, daß etliche Systemtools in FBSD GNU-Software sind oder sein müssen (grep beispielsweise, oder gmake), obwohl es dafür fast keinen rationalen Grund gibt. Ein Dateisystem mit Bitmaps und Listen ist auch nicht mehr unbedingt "state of the art" und auch nicht effizient.

ABER das ordentliche Dateisystemlayout, der professionelle Eindruck, die Konsistenz, die Manpages, die Einheitlichkeit, die Dokumentation, die Sauberkeit (auch des Codes, wobei ich für solche Beurteilungen eher der falsche bin), Systemtools aus einer Hand und ähnliches sind für mich Grund genug, FBSD zu nutzen. Persönlich wären mir etliche Sachen aus Linux lieber und ich würde sie gerne in FBSD sehen, oder umgekehrt. So muß ich mir eben das kleinere Übel aussuchen, das ist nunmal FBSD.

Es ist im Endeffekt nicht der Linux-Kernel, der mich stört, von dem 2.6er halte ich relativ viel. Es geht mir um das Drumherum, in der Regel GNU. Man gucke sich allein die Größe von der glibc an. Oder man gucke sich ps an, wo es schwer ist, durchzublicken. ps e ist nicht ps -e, ps aux ist nicht ps -aux (ist nur ein Beispiel, vielleicht ist es gerade bei -e doch identisch, habe keine Manpage hier). Das ist grauenvoll. Die Kleinigkeiten machen es aus, beispielsweise, daß man 2 oder 3 Sekunden warten muß, wenn man beim Login das Paßwort falsch eingibt. Klingt nach einer Kleinigkeit, aber die Summieren sich zu einem negativen Gesamtbild auf. Mich stört, daß /bin/sh ein Link auf die Bash ist und diese selbst im SH-Modus SH-inkonforme Syntax erlaubt. Ich mag kein GNU mehr, was ein guter Grund gegen GNU/Linux ist. (:

Mich stört die Tatsache bei Linux, daß man RPM, DEB, TGZ, TBZ2, XYZZY Paketfiles hat, jede Distro unterschiedliche Configs nutzt und trotz LSB Runlevel nicht eindeutig sind (Debian hält sich beispielsweise nicht dran, daß X in Runlevel 5 startet). Dann kommt einer mit einer Frage und hat Yast, daß Änderungen an /etc/X11/XF86Config-4 wieder durch selbstverwaltete Configs plättet und ich muß SuSE kennen, nur um jemanden bei X zu helfen. Das gefällt mir nicht.

Der Linux-Hype verursacht außerdem einen "starken" (relativ) Zulauf von Leuten, die als root arbeiten wollen, mit chmods 777 großzügig umgehen und ähnliches. Vielleicht kommt da in den nächsten Jahren noch etwas größeres auf "uns" zu. Mit FBSD gehe ich dem vorerst aus dem Weg.

Die Tatsache allein, daß ich FBSD nutze, heißt aber nicht, daß ich FBSD nun abgöttisch liebe. Teilweise ist es genial, teilweise ist es das nicht. Es ist nicht perfekt und nur weil ich es nutzt, werde ich nicht mit Kritik daran sparen. Und das XMMS das fünfzigfache an CPU-Zeit benötigt und das Sound (nicht nur bei mir) verzerrt wird, wiegt sehr schwer und hat mich lange Zeit ins Schwanken gebracht, om ich das akzeptieren kann (ich habe auch etliches probiert und hier, im IRC und Usenet gefragt, niemand konnte mir helfen, vereinzelt gab es nur Bestätigungen, daß ich nicht der einzige mit solchen Problemen bin).

DragonflyBSD könnte in dem Zusammenhang der Ports jedenfalls noch richtig interessant werden und vielleicht springt ja dabei dann auch etwas für FBSD raus. (:
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben