# eupdate-Geschwindigkeit [solved]

## psyqil

Hallo,

würd mich freuen, wenn da jemand wüßte, woran's liegt und mich aufklären könnte: Ich benutze seit geraumer Zeit esearch, und während das eupdate am Anfang zwei Minuten gedauert hat, ist es im Laufe der Zeit immer langsamer geworden, bis es zuletzt zwei Stunden waren. Jetzt hab ich am Wochenende mal revdep-rebuild laufen lassen, dabei ist python neu gebaut worden und das gestrige eupdate hat wieder zwei Minuten gedauert, juhu! Und heute:

```
 * esearch-index generated in 120 minute(s) and 6 second(s)

```

Woran bitte liegt denn sowas?Last edited by psyqil on Mon Jul 26, 2004 9:37 am; edited 1 time in total

----------

## Genone

Welche Portage Version ? Hört sich sehr nach Problemen mit dem Cache an (was bei 2.0.51 momentan normal wäre).

----------

## psyqil

2.0.50-r9, das geht aber schon seid langem so...

----------

## psyqil

So, hab mal ein neues System aufgesetzt, und es geht schon wieder los:

1. Tag: 30 Sekunden

2. Tag: 5 Minuten

3. Tag: 30 Minuten

4. Tag: 45 Minuten

 :Question:   :Question:   :Question: 

----------

## Aldo

Geht mir auch so, kann mir aber leider nicht erklären womit das zusammenhängen könnte.

Bei mir dauert es mittlerweile ca. 30-40 Minuten...

----------

## Ragin

Ich habe gar keine Probleme damit...

Schaut mal ob ihr DMA aktiviert habt.

Normal nimmt eupdatedb nur das Portageverzeichnis, sucht es durch was da ist und schreibt alles in eine kleine DB. Von daher sind solche Zeiten eher ungewöhnlich.

----------

## Aldo

 *Ragin wrote:*   

> Schaut mal ob ihr DMA aktiviert habt.

 

Ist aktiviert und wird auch genutzt von den Laufwerken.

Könnte es evtl. am verwendeten Filesystem (XFS) liegen?

Meine irgendwo gelesen zu haben, daß Datenbanken auf Journaling-FS nicht so toll wären...

----------

## Ragin

XFS ist dafür eigentlich sehr gut geeignet...

XFS kann normalerweise recht schnell mit Dateien umgehen, das heisst das Durchsuchen der Portage Verzeichnisse sollte schneller gehen als z.Bsp. auf ext2.

Die "Datenbank" die von eupdatedb geschrieben wird ist eine kleine "Textdatenbank" wenn man es so nennen will. Aber auch normale Datenbanken wie mySQL haben mit Dateisystemen wie XFS keine Probleme.

Daran kann es also nicht liegen. Welche esearch Version benutzt ihr denn genau?

----------

## Aldo

 *Ragin wrote:*   

> Welche esearch Version benutzt ihr denn genau?

 

Also ich benutze esearch-0.6.2 und portage-2.0.50-r9

----------

## dakjo

Tja, diesen effect kann ich leider auch nicht bestätigen.

```

nbbastl bastl # eupdatedb 

 * indexing: 0 ebuilds to go   

 * esearch-index generated in 4 minute(s) and 2 second(s)

 * indexed 7329 ebuilds

 * size of esearch-index: 1124 kB

nbbastl bastl # emerge esearch -pv

These are the packages that I would merge, in order:

Calculating dependencies ...done!

[ebuild   R   ] app-portage/esearch-0.6.2   0 kB 

Total size of downloads: 0 kB

nbbastl bastl # emerge portage -pv

These are the packages that I would merge, in order:

Calculating dependencies ...done!

[ebuild   R   ] sys-apps/portage-2.0.50-r9  -build -multilib -(selinux)  0 kB 

Total size of downloads: 0 kB

```

Ich benutzte auch xfs. Kann es sein das du/ihr irgentwelche links im portage habt ? 

Vieleicht hilft ja ein eupdatedb -v

----------

## Sas

Bei mir gehts mit den gleichen Versionen wie dakjo und auch XFS ebenfalls flott.

----------

## psyqil

Dateisysteme hier sind ext3 und reiserfs, wäre DMA nicht aktiv, wären ja noch mehr Sachen lahm...

 *dakjo wrote:*   

> Vieleicht hilft ja ein eupdatedb -v

 Nope! Hab denn output mal hier hinterlegt, das verteilt sich schön...

----------

## dakjo

Und wenn du mal die ganze db neu anlegst ?

----------

## psyqil

 *dakjo wrote:*   

> Und wenn du mal die ganze db neu anlegst ?

 Wie mach ich das denn? Aber wie gesagt, das System ist vier Tage alt...

----------

## Sas

Ich vermute mal einfach die entsprechende Datei unter /var/cache/edb löschen...

----------

## dakjo

Ähhm, jo, glaub schon ?

----------

## psyqil

Ja, ok, ich war in Gedanken noch beim portage-cache...

----------

## psyqil

Nope, hab' beide Dateien gelöscht und noch psyco eingebaut, aber er schleicht weiter vor sich hin...  :Sad: 

----------

## haceye

Hi,

Das ist wirklich komisch.. ehrlichgesagt kann ich mir auch nicht vorstellen woran das liegt, ich hatte noch nie große Probleme mit der Geschwindigkeit von eupdatedb, in letzter Zeit dauert es meistens 2-3 Minuten. 120 Minuten sind natürlich total daneben, leider kann ich im Moment nicht weiterhelfen.

Bald kommt übrigens esearch-0.6.3, da wird dann auch endlich das "License"-Feld mit indiziert, allerdings wird sich das wohl kaum positiv auf die Geschwindigkeit auswirken  :Smile: 

David

----------

## Silicoid

Was sagt denn ein

```

time eupdatedb

```

Wieviel Zeit wird im Userland und wieviel im Systemland verbraucht?

----------

## psyqil

Gute Frage! Antwort in ~40 Minuten...  :Razz: 

----------

## psyqil

```
cerebella root # time eupdatedb

 * indexing: 0 ebuilds to go

 * esearch-index generated in 33 minute(s) and 45 second(s)

 * indexed 7329 ebuilds

 * size of esearch-index: 1179 kB

 

real    33m44.779s

user    27m59.415s

sys     2m15.173s

```

Hm. Auch nichts neues, oder...  :Confused: 

----------

## moe

Kann zwar zur Lösung nicht viel beitragen, aber bei mir ists auch so lahm, auch portage generell, ein emerge -pu world dauert auch so um die 30-40 Minuten..

Gruss Maurice

----------

## Silicoid

 *psyqil wrote:*   

> 
> 
> ```
> cerebella root # time eupdatedb
> 
> ...

 

Damit ist auf jedenfall definitv, daß du kein IO Problem hast. Wäre hättest du eines, dann sollte IMHO sys viel näher an user sein. 

Die Frage ist jetzt was tut eupdatedb da so lange ...

Zum einen könntest du eupdatedb mal mit -v laufen lassen um zu sehen, ob bei einem Tree besonders viel Zeit verbraten wird.

Wenn du es wirklich brutal machen willst:

```
strace -ftto /tmp/eupdatedb.trace euptdatedb
```

und schaun, ob es einen Systemcall gibt, der besonders viel Zeit braucht oder sonst irgendwelche Auffälligkeiten auftreten. Aber Vorsicht, daß File wird groß. 

Würde ich auch nur machen, wenn due beim eupdatedb siehst, daß alles "ähnlich" lange braucht. Wenn das der Fall ist, einfach eupdatedb mit strace ein paar "Minuten" laufen lassen und dann drüber schauen.

----------

## psyqil

 *Silicoid wrote:*   

> Zum einen könntest du eupdatedb mal mit -v laufen lassen um zu sehen, ob bei einem Tree besonders viel Zeit verbraten wird.

 Hab' ich gestern, siehe oben, die Zeiten scheinen relativ zur Größe schon zu passen...

 *Quote:*   

> Wenn du es wirklich brutal machen willst:

 Will ich!  :Very Happy:  strace läuft, dankeschön!

----------

## psyqil

Juhu!   :Very Happy: 

Und zwar lag es daran, daß ich fauler Hund in /etc/portage/package.keywords Einträge ohne Kategorie hatte, die dann 7000 Mal im gesamten Tree gesucht wurden...hab jetzt brav die Kategorien hinzugefügt, und siehe da:

```
 * esearch-index generated in 5 minute(s) and 42 second(s)
```

  :Idea:  Vielen Dank, das hat Spaß gemacht!

----------

## moe

Cool, dasselbe wars bei mir auch!

Hab zwar im strace auch gesehen, dass er x-mal immer die selben ebuilds in allen Verzeichnissen sucht, aber dass es an portage.keywords liegt darauf wär ich nicht gekommen..

Gruss Maurice

----------

## psyqil

 :Shocked:  Blind bin ich übrigens auch, aber openoffice-ximian ist auch ohne Kategorie lang genug...  :Embarassed:  

```
* esearch-index generated in 1 minute(s) and 44 second(s)
```

dann noch '=' in '-' verbessert 

```
* esearch-index generated in 1 minute(s) and 34 second(s)
```

Yesss!   :Cool: 

----------

