# Warum dauert "Updating Portage cache" so lang?

## BlackEye

Frage mich gerade, warum das "Updating Portage cache" immer länger dauert.. Mein Gentoo ist eigentlich noch gar nicht soo lange auf dem Rechner hier (ca 4 Monate) aber das updaten des Portage-Caches nach nem "emerge --sync" dauert jetzt schon mehrere Minuten. Mir kommt es so vor, als würde es jeden Tag länger und länger dauern... Was macht der da eigentlich so lang? Installier ich ein Gentoo frisch und neu, geht das ratz fatz und er ist fertig. Aber hier zählt er die einzelnen Prozentpunkte so lahmarschig hoch, das ich in der zwischenzeit nen Kaffee trinken kann.. Frag mich nur, ob das jetzt an mir liegt oder an Portage und wie schlimm das noch wird?

BTW: Ist nen Athlon 2400+ mit 1GB RAM

Grüsse

----------

## slyght

Hab mein gentoo-sys seit gut 2 Jahren laufen und früher lief das auch bedeutend schneller. Hatte das Gefühl, dass es von ein auf den anderen Tag plötzlich seehr langsam wurde, aber warum weiß ich leider nicht.

----------

## Raistlin

Komisch, habe gestern auch das erste mal so etwas gedacht... CPU-Auslastung ca 10%...

Athlon XP 2600, 1.5GB RAM

----------

## Mr_Maniac

 *slyght wrote:*   

> Hab mein gentoo-sys seit gut 2 Jahren laufen und früher lief das auch bedeutend schneller. Hatte das Gefühl, dass es von ein auf den anderen Tag plötzlich seehr langsam wurde, aber warum weiß ich leider nicht.

 

Sehe ich auch so...

Das war vor... 1-2 Wochen?

Und seitdem dauert das auf einmal bedeutend länger...

Aber schneller ist nichts geworden  :Sad: 

----------

## ph03n1x

Das hängt wohl damit zusammen, dass immer mehr packages in portage kommen. Vor 1-2 Jahren ging das noch massiv schneller.

Meiner Meinung nach ist das portages system so, wie es zurzeit funktioniert eh veraltet. Höchste Zeit für was neues (ich weiss es wird dran gearbeitet...). Emerge -s package ist meiner Meinung nach überhaupt nicht mehr brauchbar, das dauert zu lange.

Ich helf mir mit eix ab und für den sync muss ich ja nicht vorm Computer sein...

----------

## monade

Das erklärt aber nicht warum es seit 1-2 wochen "plötzlich" deutlich länger dauert. Ich kann vom Gefühl her diesen Zeitraum bestätigen.

----------

## Raistlin

Das mit den 1-2 Wochen kann ich bestätigen --> so lange ist es nämlich her, seit ich das letzte mal "schnell" ge-emerge-synct habe...

----------

## borlander

Der Portage Cache wird nun indiziert. Das Dauert natürlich zimlich lange, aber dafür ist die Suche schneller.

----------

## pablo_supertux

Bei einer neu Installation hat mein einen relativ "leeren" /var/db/pkg

Mit der Zeit ist das nicht mehr so leer und dementsprechend dauert es seine Zeit. Ich weiß, dass es manchmal über 10 Minuten dauern kann, aber das finde ich in Ordnung, oder syncs du jede Stunde? Einmal 10 Min. warten am Tag/an einer Woche ist nicht viel, oder?

----------

## ph03n1x

Stimmpt, dann brauch ich ja eix gar nicht mehr  :Wink: 

----------

## monade

Aber alte (=schnellere) sync-Zeit + Zeit von update-eix gibt deutlich weniger als die aktuelle sync-Zeit. Also entweder indiziert eix smarter oder es gibt noch einen weiteren Grund für dieses Phänomen  :Smile: 

@borlander: wo stand das mit der Indizierung?

----------

## BlackEye

 *pablo_supertux wrote:*   

> oder syncs du jede Stunde?

 

Nein, natürlich nicht. Ein mal am Tag ist maximum. Alles Andere wäre sicherlich auch albern.. Mir ist es nur aufgefallen, dass es immer schlimmer wird.

Das der Portage nun indiziert wird, wusste ich ebenfalls noch nicht. Dafür geht das '-s' wohl schneller. Aber das '-S' dauert immernoch recht lang  :Smile: 

 *Quote:*   

> 
> 
> [mfe@murpy] (~) $ emerge -S html
> 
> [...]
> ...

 

Vielleicht wäre eine echte Datenbank mal eine Überlegung wert? Obwohl Portage dadurch wohl eher zu kompliziert werden würde... '-S' wird ja bei der Suche > 100.000 Files öffnen müssen und allein das ist ja schon ein riesen Aufwand. In naher Zukunft wird das ja eher schlimmer als besser..

----------

## Aldo

 *Quote:*   

> Vielleicht wäre eine echte Datenbank mal eine Überlegung wert?

 

Ich nehm esearch (app-portage/esearch)

Glaub kaum daß es noch schneller gehen kann...

----------

## tango

mir ist die Geschwindigkeit auch schon aufgefallen...

Zuerst lag Portage auf XFS, dort war es total lahm.

Dann hatte ich ReiserFS 3.6, hier war der Speed erheblich schneller (also das Updating Portage..)

ext2 war auch in Ordnung, momentan bin ich bei Reiser4 angelangt, welches auch recht schnell und fehlerlos läuft..

Ich denke es liegt auch am Dateisystem, ich würde aufgrund der vielen kleinen Dateien ReiserFS benutzen, damit habe ich gute Erfahrungen gemacht...

Klar nervt es, aber so oft suche ich auch nicht nach Paketen, zudem gibt es gentoo-portage.com wo man auch mal schnell nach neuen Versionen o.ä suchen kann...

tango

----------

## Sourcecode

 *pablo_supertux wrote:*   

> Bei einer neu Installation hat mein einen relativ "leeren" /var/db/pkg
> 
> Mit der Zeit ist das nicht mehr so leer und dementsprechend dauert es seine Zeit. Ich weiß, dass es manchmal über 10 Minuten dauern kann, aber das finde ich in Ordnung, oder syncs du jede Stunde? Einmal 10 Min. warten am Tag/an einer Woche ist nicht viel, oder?

 

Kann ich den denn nicht bei meinem Gentoo einfach wieder Leeren? was hätte das für nachteile? könnte ich teoretisch doch eifnach runterlöschen oder nicht?

----------

## ph03n1x

 *Aldo wrote:*   

>  *Quote:*   Vielleicht wäre eine echte Datenbank mal eine Überlegung wert? 
> 
> Ich nehm esearch (app-portage/esearch)
> 
> Glaub kaum daß es noch schneller gehen kann...

 

eix ist schneller, zumindest beim aktualisieren der datenbank, hab von esearch auf eix gewechselt...

----------

## chrib

So, ich hab mal ein wenig rumgespielt und in der Tat, ein emerge -s geht im Vergleich zu früher schneller. Allerdings dauerte der erste emerge-Befehl (egal welcher) immer elend lange. Strange.

----------

## ph03n1x

 *chrib wrote:*   

> So, ich hab mal ein wenig rumgespielt und in der Tat, ein emerge -s geht im Vergleich zu früher schneller. Allerdings dauerte der erste emerge-Befehl (egal welcher) immer elend lange. Strange.

 

Jupp ich hab gleich eix wieder geemerged. Portage ist wirklich überholungsbedürftig, was performance betrifft...

----------

## BlackEye

 *chrib wrote:*   

> Allerdings dauerte der erste emerge-Befehl (egal welcher) immer elend lange

 

Das liegt daran, dass beim ersten Aufruf von emerge oder dergleichen verschiedene Libraries in den Speicher geladen werden. Sind diese einmal im RAM sollte der Rest immer recht schnell von der Hand gehen

----------

## chrib

Ja, sowas in der Art hab ich mir nach Absetzen des Posts auch gedacht.

----------

## ph03n1x

Ich frag mich, warum hier immer parallel gearbeitet werden muss... Eix ist meiner Meinung nach fast perfekt, klein, schnell, gut zu bedienen...

Warum kann man nicht ein gemeinsames Projekt machen und das integrieren. Muss denn immer alles von jedem neuerfunden werden... sehr schade so könnte man nämlich mit vereinten Kräften bessere Lösungen erstellen.

----------

## tuxian

Muss ich für eix bzw. esearch immer den updatedb-Befehl ausführen nach einem emerge sync um deren DB aktuell zu halten?

----------

## chrib

Och, es geht einfacher. Bei esearch gab es glaub ich den Befehl esync, welcher den Portagetree aktualisierte und danach die Datenbank updatete und danach eine Liste der neuen bzw. neueren Pakete ausgab. Das Pendant bei eix heisst eix-sync IIRC.

----------

## ph03n1x

 *chrib wrote:*   

> Och, es geht einfacher. Bei esearch gab es glaub ich den Befehl esync, welcher den Portagetree aktualisierte und danach die Datenbank updatete und danach eine Liste der neuen bzw. neueren Pakete ausgab. Das Pendant bei eix heisst eix-sync IIRC.

 

Korrekt. Die Zeit die eix braucht um die db zu aktualisieren ist lächerlich im vergleich zum sync  :Wink: 

----------

## pawlak

http://de.gentoo-wiki.com/Portage_mit_cdb_beschleunigen

Bringt auch noch etwas.

----------

## hoschi

 *tango wrote:*   

> mir ist die Geschwindigkeit auch schon aufgefallen...
> 
> Zuerst lag Portage auf XFS, dort war es total lahm.
> 
> Dann hatte ich ReiserFS 3.6, hier war der Speed erheblich schneller (also das Updating Portage..)
> ...

 

Ein anderes Dateisystem, oder auch eine Datenbank vom Schlage "MySQL" sind nur ein Bugfix, keine Lösung.

Es muss entweder ein Metadatadateisystem her, oder eine kleine Minidatenbank (bloss kein MySQL, totaler Wahnsinn).

ReiserFS ist nur deswegen besser, weil es eben mit extrem kleinen Dateien gut umgehen kann, und Portage ist "leider" ein rießiger haufen kleiner Dateien - und genau deswegen total veraltet.

----------

## BlackEye

mysql wäre ausserdem ein Hindernis für spartanisch eingerichtete Server. Erst mal ein mysql-Server aufsetzen zu müssen wäre ja

a) Mit Kanonen auf Spatzen geschossen und

b) ein Sicherheitsleak mehr

es müsste imho etwas eigenes her.. oder vielleicht sowas wie sqlite oder wie das heisst?

----------

## tango

Ich habe hier ungenutzt ein MySQL-4.1.* am "laufen" (also es läuft nicht könnte aber)

Dient eben nur ganz selten mal irgendwelchen Projekten, sofern wäre es für mich, wenn es denn Geschwindigkeitsvorteile hätte lohnenswert...

Denn ein einfaches skip-networking wird wohl noch der großteil in die my.cnf reinbekommen  :Wink: 

Mit der Modifizierung im Wiki, dem ReiserFS Dateisystem, welches mit kleinen Dateien, die zweifelsohne in Portage anfallen effiziennter zurecht kommt ist es akzeptabel..

Aber bedenkt das Portage auch nicht kleiner wird, wird ja im Laufe der Zeit immer schlimmer..

tango

sry für die Rechtschreibung habe leider keine Zeit mehr   :Mad: 

----------

## BlackEye

 *tango wrote:*   

> Denn ein einfaches skip-networking wird wohl noch der großteil in die my.cnf reinbekommen 

 

mag sein.. aber bedenke die user/passwort geschichten. Es muss ja eine allgemeine Lösung gefunden werden. Obendrein würde mit einem echten Server noch ein zusätzlicher Supportaufwand anfallen, der wiederum mehrere Fehlerquellen zutage bringen kann. Mit einem solchen System wird Portage nicht einfacher, vielleicht schneller, aber sicher auch ungleich komplizierter für die Allgemeinheit zur Verfügung zu stellen sein. Kann ich gut nachvollziehen, wenn das nicht gemacht wird.

So eine Lösung kann IMHO nur eine geniale Lösung für Freaks sein, die sich mit so einem Thema richtig gut auskennen. Aber lass mal nen Problem entstehen bei einem Anfänger, wenn irgendwas mit dem SQL-Server ned stimmt und danach Portage ja faktisch gar nicht mehr geht  :Smile: 

Gruß

----------

## chrib

 *BlackEye wrote:*   

> mysql wäre ausserdem ein Hindernis für spartanisch eingerichtete Server. Erst mal ein mysql-Server aufsetzen zu müssen wäre ja
> 
> a) Mit Kanonen auf Spatzen geschossen und
> 
> b) ein Sicherheitsleak mehr
> ...

 

Mal abgesehen davon, wenn Portage plötzlich mysql nutzen würde, dann müsste man auch andere freie Datenbanksystem unterstützen. Ich z.B. möchte nicht, dass neben meiner Postgresl-Instanz noch zusätzlich mysql läuft, nur damit ich weiterhin mit Portage arbeiten kann. Unterstützt man allerdings mehrere RDBMS, bindet das wieder Entwicklungsresourcen, die woanders sicherlich dringender benötigt werden.

----------

## ph03n1x

 *pawlak wrote:*   

> http://de.gentoo-wiki.com/Portage_mit_cdb_beschleunigen
> 
> Bringt auch noch etwas.

 

Wow cdb bringt wirklich enorm viel. Ich würd sagen dauerte nur ca. 1/4 so lange wie vorher  :Wink: 

Danke für den tipp

----------

## karabela

LOL, und ich such schon die ganze Zeit, was an meinem System kaputt ist, weil

das so lahm geht...   :Laughing: 

----------

## ian!

 *Rafer wrote:*   

>  *pablo_supertux wrote:*   Bei einer neu Installation hat mein einen relativ "leeren" /var/db/pkg
> 
> ... 
> 
> Kann ich den denn nicht bei meinem Gentoo einfach wieder Leeren?

 

Bitte nicht. Da liegen die ganzen Informationen über die installierten Pakete auf deinem System.

----------

## MALON3

cdb is wirklich spitze!

geht um einiges scheller  :Smile: 

gruß

----------

## misterjack

 *chrib wrote:*   

>  *BlackEye wrote:*   mysql wäre ausserdem ein Hindernis für spartanisch eingerichtete Server. Erst mal ein mysql-Server aufsetzen zu müssen wäre ja
> 
> a) Mit Kanonen auf Spatzen geschossen und
> 
> b) ein Sicherheitsleak mehr
> ...

 

das beste wären useflags ala mysql etc, mit dem man steuern kann, wie portage nun arbeiten soll  :Wink: 

----------

