INDEX genererieren DAUERT - Warum eigentlich?

Herakles

Profifragensteller
Sagt mal, ein

Code:
portsdb -uU

benötigt EWIGKEITEN. Mich würde mal interessieren, wieso das so ist, also was genau der Rechner da alle so macht. Er erstellt da ja nur eine INDEX, aber wass genau beansprucht die CPU da eigentlich so krass?

Würde mich mal rein interessehalber interessieren... Weer weiß es als erster?


Herakles
 
Jo, würd ich auch gerne wissen.. Aber bei 12.000+ Ports ist es denk ich mal kein Wunder. Trotzdem, auf einer SMP Maschine mit insgesammt 100% Auslastung dauert es schon ca. 10-15 Minuten um solch einen INDEX zu bauen...
 
Weil die Informationen in die INDEX geschrieben werden muessen und diese Informationen abzufragen dauert einige Zeit und kostet Performance. Wem das zulange dauert, soll nice(1) verwenden, aber solche Prozesse stoeren nicht sonderlich wenn man sie nachts via cron(8) ausfuehren laesst, waehrend man schlaeft.
 
und noch eine frage rein interessehalter:

was genau bewirkt "portsdb -uU"?
 
Code:
(sicrash@insecure) [/usr/ports]% sudo make fetchindex                     19:53
INDEX-5.bz2                                   100% of  605 kB   17 kBps 00m00s
(sicrash@insecure) [/usr/ports]% sudo time portsdb -u                     19:54
[Updating the portsdb <format:dbm_hash> in /usr/ports ... - 12226 port entries found .........1000.........2000.........3000.........4000.........5000.........6000.........7000.........8000.........9000.........10000.........11000.........12000.. ..... done]
       11.55 real         5.95 user         1.70 sys

@Enterhaken
$ man portsdb(1)
 
Hallo Herakles, hallo nintendo,

der Grund für diese langen Zeiten liegt darin, dass die Abhängigkeiten berücksichtig werden müssen. Dies ist ein rekursiver Vorgang, der durch
(*) CPU-Geschwindigkeit (ruby-Skript)
(*) Geschwindigkeit und Güte des ruby-Interpretierers
(*) Festplattengeschwindigkeit
(*) Größe des Arbeitsspeichers (swap-File -> Festplattengeschwindigkeit)
(*) Anzahl der Ports und deren Abhängigkeiten
bestimmt wird.

Ich hoffe, Deinem Wissensdrang nachgekommen zu sein:D

Viele Grüße

Jürgen
 
portindex /usr/ports/sysutils/portindex soll schneller sein und auch bei nicht kompletten porttrees funktionieren. Wenn man die ganzen russischen vietnamesischen etc. ports beim cvs unberücksichtigt läßt)
 
man kann auch in /usr/ports/ ein make fetchindex machen, dann kann man sich das ganze sparen. ich weiss allerdings nicht wie oft diese INDEX aktualisiert wird, koennte unerwuenschte nebenwirkungen haben.
 
Deamon schrieb:
portindex /usr/ports/sysutils/portindex soll schneller sein und auch bei nicht kompletten porttrees funktionieren. Wenn man die ganzen russischen vietnamesischen etc. ports beim cvs unberücksichtigt läßt)

Unter /usr/ports/sysutils gibts bei mir kein Directory "portindex". Wurde das Tool aus den Ports entfernt oder umbenannt ?
 
Bei neuen Portupgrade-versionen wird anscheinend automatisch ein make fetchindex anstatt einem portsdb -Uu ausgeführt. Viel besser.

Gruß, I.MC
 
Wenn ich nicht irre, ersetzt das "make fetchindex" die INDEX Datei, die eigene DB INDEX von portupgrade aber nicht.
Wenn ich nun ein cvsup der Ports mache, danach "make fetchindex" und danach "portversion -v | grep "<"" aufrufe, werden da die zu aktualisierenden Ports auch angezeigt, oder eben nicht da die DB INDEX von portupgrade noch auf einem alten Stand ist?

Hintergrund: Ich habe zwei Systeme aber unterschiedliches Verhalten was dies angeht. Beide auf dem gleichen Stand.
 
@asg
Deshalb auch make fetchindex && portsdb --update

@I.MC
Hast du Quellen dazu? Ich kann nichts darüber finden, dass portupgrade 'make fetchindex' aufruft.
 
Seitdem ich die neuste Version von Portupgrade auf den Systemen unter 5.3 habe scheint portupgrade die INDEX.db über die INDEX-5 zu aktualisieren. Dies geschieht immer, wenn die INDEX.db älter ist also die INDEX-5. Die Datei INDEX gibt es hier überhaupt nicht mehr.
Zudem scheint portupgrade das Alter der INDX-5 zu überprüfen, denn selbst wenn ich vor 2 Tagen noch eine aktuelle INDX-5 gezogen haben mittels make fetchindex (holt die INDEX-5), wird dann trotzdem erst einmal ein make fetchindex aufgerufen bevor die INDEX.db aktualisiert wird. Da die INDEX-5 angbelich alle zwei Tage aktualisiert wird ist ein portsdb -uu in meinen Augen ein Teil der Vergangenheit :-)

Code:
SU spielen /:portversion
INDEX-5.bz2                                   100% of  607 kB   52 kBps 00m00s
done
[Updating the portsdb <format:bdb1_btree> in /usr/ports ... - 12249 port entries found .........1000.........2000.........3000.........4000.........5000.........6000.........7000.........8000.........9000.........10000.........11000.........12000.. ..... done]
bash                        <
cvsup-without-gui           =
exim                        =
expat                       =
fontconfig                  =
freetype2                   =
gettext                     <
glib                        <
gmake                       =
imake                       <
lame                        =
libiconv                    =
libslang                    =
libtool                     =
mc                          =
mldonkey-core               =
mplayer                     <
mplayer-skins               <
nasm                        =
perl                        =
pkgconfig                   =
png                         <
portaudit                   =
portupgrade                 =
ruby                        =
ruby18-bdb1                 =
screen                      =
win32-codecs                =
xorg-libraries              <

Gruß, I.MC
 
roman schrieb:
man kann auch in /usr/ports/ ein make fetchindex machen, dann kann man sich das ganze sparen. ich weiss allerdings nicht wie oft diese INDEX aktualisiert wird, koennte unerwuenschte nebenwirkungen haben.
Ich benutze seit einigen Monaten "make fetchindex" mehrere Male pro Woche (*). Der Index ist wirklich immer aktuell, meist nicht einmal eine Stunde alt. Ich hatte bisher auch noch keine Probleme damit. Ich kann diese Methode daher nur empfehlen.

(*) für einen IRC-Bot der von anderen IRC-Teilnehmern abgefragt werden kann

Gruß Björn
 
Zurück
Oben