Emerge sync takes forever, uses 98% CPU

i92guboj · Posted: Sun Sep 25, 2005 4:34 pm Post subject:

Reiserfs or reiser4 are not valid options for me, too much cpu cycles eaten. Ext2 is fast, and uses much less memory and cpu, because it dont do journaling (i dont need journaling in portage, /var and /temp. I use xfs for / and all the thing goes so smooth.

Maybe the fs is getting a bit fragmented, I will to to tar, clean it and untar again to see if that makes any difference. Thanks for remembering me that. Im also going to check this thing: https://forums.gentoo.org/viewtopic-t-341900-postdays-0-postorder-asc-start-25.html

lost+found · Posted: Sun Sep 25, 2005 4:56 pm Post subject:

You're right, I don't like Reiser for that reason too, and Ext2 is fastest. I hope a future redesign of Portage will improve things like speed and storage. Defragmenting should be a hobby of M$ OS owners. ;-)

nixnut · Posted: Sun Sep 25, 2005 5:11 pm Post subject:

Merged two "portage slow with high cpu usage" threads here.
_________________
Please add [solved] to the initial post's subject line if you feel your problem is resolved. Help answer the unanswered

talk is cheap. supply exceeds demand

i92guboj · Posted: Sun Sep 25, 2005 5:13 pm Post subject:

We agree on that. On scenaries where fs integrity and journaling is not imperative the smart option is ext2. In adiction I use ext3 when I need security, for example in /home (well tested and efficient fs). For things like the os, I preffer xfs, that has journal, but is relatively soft in my cpu (I also like jfs but I had some stability problems with it in the past). Some years ago I used to use reiserfs, but I discovered a big interactivity and responsiveness boost when I left it behind.

I also tested reiser4 some months ago, but I just could not stand with it, so much problems and very heavy on cpu for my personal taste. At least it is true that is faster when manipulating tons of small files, but nothing special at all. And in some other circunstances it is slower (objetively tested with bonie++ by myself).

I think that, for now, I will have to test if the defragmentation changes anything :wink:

lost+found · Posted: Sun Sep 25, 2005 6:14 pm Post subject:

Don't know if fragmentation is the cause of high cpu%, people talk about. Maybe this is of any use with emerge --sync:

/etc/make.conf:

i92guboj · Posted: Sun Sep 25, 2005 6:21 pm Post subject:

I already have a high portage niceness (and yes, I tried to lower it and even disable it, and the metadata processing is still so slow). I also use the noatime option to mount my partitions. With ext3, ext2 and xfs I dont have cpu problems, the cpu usage is low, even when doing massive io, the problem is the high amount of time that emerge requires to "emerge metadata". Tonight I will move my portage tree into another partition, then recreate the fs in the actual portage partition, and move the fs back once the partition in empty and remounted. I will tell you if that makes any difference or not, probably tomorrow the thing should be up and running again. :wink:

lost+found · Posted: Sun Sep 25, 2005 7:08 pm Post subject:

...Good luck! Please post if things be beter after this.

(Don't forget to tar /var/cache/edb, or just delete the contents, it will be recreated by a current version of portage anyway...)

Never delete /var/db/pkg.

brianahr · Apprentice Joined: 07 Oct 2004 Posts: 236 Location: USA

So I noticed there are a ton of threads on this topic. And they all seem to be a bunch of people with the same problem. On my machine, it takes about 7 minutes of 100% CPU to emerge --sync. And this thing is a 2.6Ghz machine, 512mb RAM, no binaries. It is pretty annoying though, I must admit. From what Ive read, it seems like using the database backend for portage only makes searching faster, not syncing. (Havent actually tried it yet, though) A lot of people seem to atttribute this to the fact that portage is huge, and all of that stuff is left directly on the filesystem, instead of in some database. Does anyone know for sure if using the database speeds up or slows down the sync? It kindof seems hypocritical to have blazing-fast-omg-optimized gentoo systems, if portage so omg-I-want-to-shoot-something-slow. (Im sure Ill get flamed for that one, haha) Regardless, I think theres got to be something we can do to fix it.

i92guboj · Posted: Sun Sep 25, 2005 9:09 pm Post subject:

A database would be inherently faster, as it is much faster to read a big single file that to read a 130.000 smaller ones. There are some topics and a couple of projects. One of the using db and c++, and another using sqlite and c (not sure) but none of them seems to be so mature yet.

You are right in one thing: as portage grows this can only get worse, and worse. Two or three months ago portage was about 100k files, now it is near 130k or 140k files, and surely, before the year ends, portage will be (if the thing continues this way) about 170-190k files. That is a very insane number, just to manage the installation of packages. It is a huge number, and when the number of files grows so much the degradation in the performance is not lineal, instead it degradates faster and faster each time a file is added to portage. That and python will make portage unusable in some months for any other use appart of emerging thing.

By the time I installed Gentoo the first time, it would take me about 3-5 mins to make an emerge --searchdesc, no, I use it only very rarelly, and when I have no other option, because it can take even 20 mins, at least the first time (then it is faster).

xtaski · Posted: Sun Sep 25, 2005 9:44 pm Post subject:

lost+found · Posted: Mon Sep 26, 2005 4:50 am Post subject:

With ReiserFS you should drop "notail" to get a performance increase on small files...

I think future Portage should provide a choice to download all, or just the ebuilds you actually use. When people want to read or browse all ebuilds available, it could be done online. Just like why I don't need to download all postings in this forum to find what I want to know.... But after all, it's a luxury problem. We are really spoiled with all the things we can install the easy and the best way (although time consuming), if you compare to other distro's. :-)

rk_cr · n00b Joined: 14 Jan 2004 Posts: 12

I just want to add that I am also having problems of slow syncs.

However, this is on a clean machine (only a month old installation of Gentoo) with Reiser. All stable packages, only three binaries (and the buildpkg feature is turned off). Within two weeks of updating the cache slowed down quickly.

How could in two weeks of an installation the cache go from instant updates to slow as hell (around 50%)? Sounds more like a coding efficiency error than a bloated file system. If it was portage then I would've gotten slow performance from the get go, but that just wasn't the case.

Is anyone here an expert on what's going on behind updating portage cache?

JSharku · Posted: Mon Sep 26, 2005 3:23 pm Post subject:

i92guboj · Posted: Mon Sep 26, 2005 4:47 pm Post subject:

It is evident that the implementation does also count in this. But, really, you can't think that a filesystem is the better way to handle this huge thing that portage is becoming into. I think -thou im not "the master of universe" and could easily be wrong- that the problem is not only one, but fatidic a combination of factors:

-First, the portage tools could be faster (preferably not in python)

-Second, the filesystem becomes more important while the tree keeps growing and its performance degradates in a non lineal manner that increases the perfomance degradation curve faster and faster each day that portage grows.

-Being also a filesystem that can be rsync'ed by an average of two-four times at a month (some people do it even many times every week) the fragmentation problem is not the same fragmentation problem that you can find in a more static filesystem. To agravate the problem there is the big number of files. Some fs's (like reiser[fs/4] provides a mechanism that is better to keep these huge amount of small files into a single cluster, which also make reads faster for these, but at a price (a very expensive price on cpu cycles for my likings, which is not acceptable at all).

ugus · Posted: Mon Sep 26, 2005 7:50 pm Post subject:

suineg · Posted: Tue Sep 27, 2005 12:08 am Post subject:

I have also noticed this, I am on reiserfs, so for those of you who were asking, it has the same problem (at least in my case)

This has been the case for me for well over a month...

xtaski · Posted: Tue Sep 27, 2005 2:16 am Post subject:

Seems to me this is a bug in portage - has anyone filed a bug?

JackDog

When I perform an 'emerge sync', the updating of the portage cache is taking 7 minutes to complete. This is an older gentoo system (>2 years). What can I do to reduce time it takes for this procedure?
_________________
Are you intolerant of intolerant people? Tired of being PC yet?

lghman · Guru Joined: 29 Nov 2002 Posts: 548 Location: Florida

There are already multiple threads on this problem. This being the most talked about https://forums.gentoo.org/viewtopic-t-384292-highlight-portage+cache.html

--sonik
_________________
"What a distressing contrast there is between the radiant intelligence of a child and the feeble mentality of the average adult" --Freud

JackDog · Posted: Tue Sep 27, 2005 3:18 pm Post subject:

I am experiencing severe slowdowns that have worsened in recent months. I am now at a 10 minutes emerge sync with 7-8 minutes of that spent on "Updating Portage cache". I do not have buildpkgs set and dont have any binaries laying around. This machine contains a >2 year old intallation that is kept up to date on a weekly basis. Newer machines do not have this problem.

Whats sad is this is a p4 2.5Ghz machine with a 7200 rpm drive.

Any ideas on how to alleviate this issue? Like I said it only seem to get worse over time.
_________________
Are you intolerant of intolerant people? Tired of being PC yet?

nixnut · Posted: Tue Sep 27, 2005 3:31 pm Post subject:

Above three posts merged here.
_________________
Please add [solved] to the initial post's subject line if you feel your problem is resolved. Help answer the unanswered

talk is cheap. supply exceeds demand

i92guboj · Posted: Tue Sep 27, 2005 4:18 pm Post subject:

Hi again people.

I did some research. Last night I put my personal box to defragment my /dev/hda7, which is the partition that I have dedicated only for my portage tree. As I said in any other post, it is about 10 gb in size, and holds also all my distfiles. 7.2 gb of that space is filled, that is... 72 % of the space in that partition.

I defragmented my portage by simply doing:

lost+found · Posted: Tue Sep 27, 2005 5:27 pm Post subject:

Thanks 6thpink, for testing. Until Portage changes, using this workaround is not a big deal. I think I will make a loop file of ext2, with a smaller block size, to keep my reduced Portage with rsync_excludes... :-)

morbid · Tux's lil' helper Joined: 05 Mar 2003 Posts: 90

My new system is only DAYS old and is experiencing this issue (portage cache update hanging at 50% for a long time). I also saw this issue on all of my other systems, and it began around the same time (like 1-2 weeks ago). I was under the assumption it was the kernel I was using (2.6.13-archck?), but I doubt everyone else here is running that. I am also syncing against my own server, so I know it's not bandwidth, and the server is fine too.

And for those of you that blamed reiserfs or reiser4. When my partitions were ext2, sync would take about 3 mins. With reiser4, it took about 30 seconds (until this recent issue).

So... I don't think this is a filesystem (type or level of fragmentation) issue. I think it has to be something else... like portage or rsync. What versions is everyone running? I'm at:
sys-apps/portage-2.0.52-r1
net-misc/rsync-2.6.6

xtaski · Posted: Tue Sep 27, 2005 11:23 pm Post subject:

I don't think this is a filesystem issue either - I have reiser which as far as I know doesn't "fragment" - I got it to speed up by clearing out the packages dir, but then the next sync it took forever again...