| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Jeremy Brake wrote: |
| 5 |
> How about speeding up the wait time on updating the portage cache after |
| 6 |
> a sync.. even on my AMD 64 3500 it takes a number of minutes to chug |
| 7 |
> through.. |
| 8 |
> are there any known ways to "vrrmmm" this up a little? |
| 9 |
> |
| 10 |
> Jeremy |
| 11 |
|
| 12 |
Well the current problem is that in the 2.0 portage branch the cache |
| 13 |
code sucks. This is fixed in ~arch portage ( the 2.1_pre series ). For |
| 14 |
you users that don't want to upgrade to unstable, you should be able to |
| 15 |
use cdb to speed up the process. |
| 16 |
|
| 17 |
Setting RSYNC_EXCLUDES will not speed up the second half of the --sync ( |
| 18 |
the --metadata portion ). |
| 19 |
|
| 20 |
Explanation: The Portage Tree has a ton of ebuilds in it, when you do |
| 21 |
something like emerge -pv <blar> portage used to have to go read each |
| 22 |
ebuild and be like "oh what are the USE flags, the dependencies, etc.." |
| 23 |
This takes a lot of time, especially for something like emerge -uD world |
| 24 |
that may touch thousands of packages. |
| 25 |
|
| 26 |
So to mitigate this issue portage has a "metadata cache" where it stores |
| 27 |
the ebuild metadata so it doesn't have to source each ebuild every time. |
| 28 |
This gives performance increases ( reportedly ) of 100x speed-ups. |
| 29 |
|
| 30 |
However, generating the metadata is time consuming, even on decent |
| 31 |
hardware it will probably take 30-45 minutes. To not piss the users |
| 32 |
off, Gentoo calculates this metadata serve-side and serves it to you |
| 33 |
during sync. |
| 34 |
|
| 35 |
The Rsync portion of emerge --sync is pretty much everything before the |
| 36 |
"updating metadata cache". This should be pretty standard as far as |
| 37 |
time goes on all boxes. However the second portion is where portage has |
| 38 |
to take the generated server-side cache and kind of "meld" it into your |
| 39 |
already existant local cache ( stored in /var/cache/edb/dep for those of |
| 40 |
you whom are curious ). This didn't used to take a bunch of time..until |
| 41 |
KDE split their packages from KDE-monolith to KDE-meta. The X.org |
| 42 |
switch probably won't help much in this area either. Particularly the |
| 43 |
slowdown at 50-52% is due to this portion of the tree. |
| 44 |
|
| 45 |
There is a new cache system in the 2.1 branch of portage, or using cdb, |
| 46 |
or perhaps even an sqlite back-end (patches and modules are out there), |
| 47 |
will help until such time as the 2.1 branch is stablized ( probably not |
| 48 |
too soon ). |
| 49 |
|
| 50 |
- -Alec Warner (antarus) |
| 51 |
|
| 52 |
Disclaimer: I'm not a developer (yet) but I've worked with the portage |
| 53 |
team for some time. Release dates, features, and other things are not |
| 54 |
gauranteed to be correct just because I said so :) |
| 55 |
-----BEGIN PGP SIGNATURE----- |
| 56 |
Version: GnuPG v1.4.2 (GNU/Linux) |
| 57 |
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org |
| 58 |
|
| 59 |
iQIVAwUBQ9CExWzglR5RwbyYAQLJEhAAj7i2cRVgv1iBfi61mGkn9q1t/K5JEJcv |
| 60 |
zK07bTmMDirviessdKiZVSufXdWV79tW0MDEVqmGI9t+V+uwM77aFbge1VSkEaQB |
| 61 |
RWetuQL8tQRUX1KvQ+ItScVtbqKIAQe/Jn+BwSim05jF3+fF15Z6EpPPKypNLQxK |
| 62 |
2ef/bcJ91Gctv0xcd6j943uOPFDCt05Ahe06/pQ0wgGdnAcKLOy/RVwDOVfprXim |
| 63 |
AwiVsU4aCxRI056RkEj1VuSwSYQEa91WKpTGv81lZVkRW8LRxkgc7UAydMYGjOY5 |
| 64 |
1prjv2Koyly5ycVvxshKVmLfuaqByY9bBnlklyKDdFW1ZD1udCflCLxmz3GuTCsm |
| 65 |
/FHce+Y9smqq3sF1wV7DYXu9vTnLdBqVBlDq4cEtd5XdgQm3TJ5rUGF2Mepicyhg |
| 66 |
Bg4ibDExDB5eKWCnGU3ioSCd8TY9cdR9ZXxpm6JLGfr9ztog0/vScsIZbj3dS4RH |
| 67 |
WqGklvW0F9N6NjP26WJwtQsmSIZpSJU4yPxneZOdQxGOUfdNPQap+qO+rZaitPKW |
| 68 |
yWaikaiSuecPSul0ithpGnCFttPHrBLyNKNl7aom04Bht4KSdaqzriIL/RylWzHW |
| 69 |
OgazUV9RuVdI8oEx+q3zKzOgvG3dXeL7HNdhH+j9noIyGVa8ouNHWMGfFUc1baxV |
| 70 |
7eyB1buSeQY= |
| 71 |
=vWqe |
| 72 |
-----END PGP SIGNATURE----- |
| 73 |
-- |
| 74 |
gentoo-performance@g.o mailing list |
Archives