Re: [gentoo-user] Portage performance dropped considerably
On Sun, 26 Jan 2014 16:35:43 +0200 Nikos Chantziaras rea...@gmail.com wrote: Anyone else noticed this yet? Some portage update seems to have made emerge -uDN @world perform about 10 times slower than before. It used to take seconds, now it takes about 4 minutes only to tell me that there's nothing to update. And it does that every time, even directly in succession and with the caches warm. Is it just me? (TL;DR: It is a known problem and it will be improved.) More people experience this, I've seen multiple reports in all the communication channels I can think of so far; besides having been bothered with it myself in the past, but now I'm fine with ~30 seconds. === What is going on and what is a cheap solution? === Often this is due to backtracking going mad; Portage keeps trying again, and again, and ... until it has done it for a 10 extra times. And if a single time perhaps takes like 30 seconds, doing it 10 times extra gets you quickly to get to 6 minutes or so. Now imagine 30 times... For this reason, I run --backtrack=0 myself; which finishes in half a minute or so, but it needs some more experience to deal with the output that comes after that as you'll need to fix up some things manually. Not to forget --backtrack=0 has some side effects wrt package rebuilds; I don't know the fine details, but was warned about this by others. A solution in between would be to use --backtrack=0 and when that isn't satisfied raise it a bit until satisfied; if you can get your --backtrack=0 to work one or another time, you know you won't need --backtrack=10 soon given that your Portage tree is pretty satisfied. When you need to raise it, you will come around with --backtrack=5; and in the case it doesn't you can raise it again, 3 minutes don't hurt. So, it can be perceived as a trade-off between I can quickly do this myself (given a good understanding of the output) and Spent some time doing it for me (if you don't have the time to do it yourself). === Why is this becoming worse over time? === Simply put, it's a growth in complexity; we've moved to newer EAPIs that bring newer features, we have packages improving and thus providing more USE flags depending on more, we've got more overlays to pull interesting packages from, as a consequence of the newer EAPIs there are a lot of sub slot dependencies and the list goes on... The more options Portage has to consider, the more time it will spend on it; and if after going down a set of options Portage doesn't find a satisfiable state, it has to backtrack with more and/or different options to try again to find another satisfiable state. You can see that the amount of options (= amount of overlays, packages, versions, enabled USE flags, ...) takes a huge toll here (amongst other things). To get an idea of what an @world emerge is doing by default, check: https://gist.github.com/TomWij/65a61765ea03e6188a35 This is generated using the output additions from the attachment of: http://article.gmane.org/gmane.linux.gentoo.user/272117 Those whom are interested can also find call tree graphs, although these rather reveal ~2% improvements because huger improvements require an actual understanding of how most code works together; they are here: http://dev.gentoo.org/~tomwij/files/portage-2.2.7-python-2.7-backtrack-0.png http://dev.gentoo.org/~tomwij/files/portage-2.2.7-python-2.7-backtrack-0-hot.png http://dev.gentoo.org/~tomwij/files/portage-2.2.7-python-3.3-backtrack-0.png (Generated with https://code.google.com/p/jrfonseca/wiki/Gprof2Dot) From the output additions you can see that the slot operators (and thus sub slots from the newer EAPIs) take up quite a few time. If you think about what these slot operators are trying to solve, you'll remember something along the lines of `revdep-rebuild` from a while ago. A lot of time we've used to spend in that back in the days has moved towards a cocktail of slot operators and preserved-rebuild. So, part of the extra time we experience is just a move of time; but that doesn't make it additional time (unless with lots of backtracking). Tried to keep this layman explanation short; as I no longer intend to make this more than a simple explanation, I used to share further details in the past but I do no longer deem them as necessary today. Why? Because Portage developer Sebastian Luther (few_) is working on improving this; the results seem promising, so, let's await a Portage release with that before we continue to look into this again. === What might be done to improve this? === Read this message (patch in second mail): http://thread.gmane.org/gmane.linux.gentoo.portage.devel/4231 The results look promising; it goes from 9:28 to 1:59, whereas --backtrack=0 is 1:38. In other words, it gets quite close to the time of --backtrack=0 without bringing its disadvantages; as it still does the conflict resolving that backtrack does, but somewhat different. (There are some other smaller patches that also spare out time;
Re: [gentoo-user] Portage performance dropped considerably
On Sun, 26 Jan 2014 16:53:33 +0100 Mariusz Ceier wrote: No, it's not just you, running emerge -uNDvp world takes slightly over 18 minutes on my laptop (i5 M 430 @ 2.27GHz) - and when there was lot to update I had to wait over 1hr to just get the list of packages. I wonder if there's some profiling tool for portage. Also: time FEATURES=-xattr emerge owncloud -v real6m31.202s user2m42.057s sys 2m1.541s time FEATURES=xattr emerge owncloud -v real30m15.632s user22m44.369s sys 5m30.129s 5 times longer - for something that's essentially copying files. Slow xattr is a known problem, see bugs 482290, 465000: https://bugs.gentoo.org/show_bug.cgi?id=482290 https://bugs.gentoo.org/show_bug.cgi?id=465000 But xattr bug shows itself during install phase and has nothing to do with dependency calculation time mentioned in the original mail. Best regards, Andrew Savchenko pgpZwwW6J9EA7.pgp Description: PGP signature
Re: [gentoo-user] Portage performance dropped considerably
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/30/2014 07:15 PM, Stroller wrote: On 30 Jan 2014, at 03:50 am, hasufell hasuf...@gentoo.org wrote: I just tried paludis again (after some time). ... * you cannot unmask USE flags at all, not without hackery... and that is really non-trivial for unmasking abi_x86_32 globally, because those masks are scattered across a lot of files in profiles/ The explanation from the paludis developer is simply wrong: http://paludis.exherbo.org/trac/ticket/817 WONTFIX: you can hack around it with your own profile if you need to deal with Gentoo not following its own policies correctly. Yes, that's the Ciaran McCreesh I remember. Stroller. The thread gets funny. I guess this is not so much about NIH, but rather about the fact that no one wants to work with him or that no one wants to be one of his users and gets his feature requests all RESOLVED WONTFIX. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS7AKzAAoJEFpvPKfnPDWzKAkIAKEIAx/4l690pHYvxvKkaypJ XWPs+LRokNboyzXyeZLEgWhEIJ5LzflBMgcnn0KRRn3p81JYaERQ+Cnx3yBtL148 7ovlZug12dxLO+nWVajrOWP3YWcHV12Kla6q7qTWrTO4RxZbfNEncyyMc4uMzCyk mQ13nBP7gooNdRx5pN61POKI23OPyK4Z/AnlJdMq6aForVuY788vOUZq8q/n96MU tdkx7npzJVJ/OGgwIF5AqIn1G1NmzmkQ3R8hKnPN/0W+l6jlChoocq+9tELTnJ/r UtXmVwdlsHCnG4rY+RxeVBIfLMi0f9xce1/ckENbLIiyoj5xMNkZ3/+6dyI/VhU= =FIJW -END PGP SIGNATURE-
Re: [gentoo-user] Portage performance dropped considerably
On 30 Jan 2014, at 03:50 am, hasufell hasuf...@gentoo.org wrote: I just tried paludis again (after some time). ... * you cannot unmask USE flags at all, not without hackery... and that is really non-trivial for unmasking abi_x86_32 globally, because those masks are scattered across a lot of files in profiles/ The explanation from the paludis developer is simply wrong: http://paludis.exherbo.org/trac/ticket/817 WONTFIX: you can hack around it with your own profile if you need to deal with Gentoo not following its own policies correctly. Yes, that's the Ciaran McCreesh I remember. Stroller.
[gentoo-user] Portage performance dropped considerably
Anyone else noticed this yet? Some portage update seems to have made emerge -uDN @world perform about 10 times slower than before. It used to take seconds, now it takes about 4 minutes only to tell me that there's nothing to update. And it does that every time, even directly in succession and with the caches warm. Is it just me?
Re: [gentoo-user] Portage performance dropped considerably
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/26/2014 03:35 PM, Nikos Chantziaras wrote: Anyone else noticed this yet? Some portage update seems to have made emerge -uDN @world perform about 10 times slower than before. It used to take seconds, now it takes about 4 minutes only to tell me that there's nothing to update. And it does that every time, even directly in succession and with the caches warm. Is it just me? Some people don't follow PMS when writing ebuilds which could be one reason. https://bugs.gentoo.org/show_bug.cgi?id=174407 https://bugs.gentoo.org/show_bug.cgi?id=487846 https://bugs.gentoo.org/show_bug.cgi?id=393203 https://bugs.gentoo.org/show_bug.cgi?id=486566 https://bugs.gentoo.org/show_bug.cgi?id=434246 https://bugs.gentoo.org/show_bug.cgi?id=311267 toolchain has closed all relevant bugs as WONTFIX so far and even QA does not seem to care enough (?), although there are alternative approaches to fix the lack of USE-dynamic SLOTS. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS5R9dAAoJEFpvPKfnPDWz6zkH/13KbO6s3d5GWe4yXJsL1C7G xOx24vTwWkeEqmi7+kUxR5Y3LUmZ0Pl4E9n//q5KcgVouKtalwFmqNaVsxQSLG9h VyRZgGNdvcvTYfdlch8VoiIhUiP+1ZaOsZFuHTOzzfw3qoc52LceJYSyV/lo/x/9 Qe6xT+TuTyUzRJunBFTEzsool8hEhu1UWPYfmjTbZ94wRgSuu68yuL/7hIr75sin cjEWo25MGzXzf8IhgfM+nI37gurPX136aLuc+JGLTUnYqN9SC1Ad2wjtvHqWJ54O /kfVlL0790v+l2HyV8CfBs3Z3LktaE7EOgEJBzogHhuO1tjDaoERYDGoE+30pK4= =tCmP -END PGP SIGNATURE-
Re: [gentoo-user] Portage performance dropped considerably
On Sun, Jan 26, 2014 at 6:35 AM, Nikos Chantziaras rea...@gmail.com wrote:
Anyone else noticed this yet? Some portage update seems to have made emerge
-uDN @world perform about 10 times slower than before. It used to take
seconds, now it takes about 4 minutes only to tell me that there's nothing
to update. And it does that every time, even directly in succession and with
the caches warm.
Is it just me?
Usually this occurs when you have done something that causes portage
to stop using the metadata that rolls in via rsync. The classic
example of something that will cause this is setting some
eclass-overrides in /etc/portage/repos.conf.
As of yesterday, portage still performed tolerably on a relatively
vanilla base system.
That stated, you're not hallucinating. Portage is slow as tar. I
suspect it's getting slower at least partially as a result of the
recent explosion of multilib-build-based ebuilds for multimedia and
x11 library ebuilds, and perhaps also due to those nasty
emul-linux-x86 blockers (a problem that will eventually be resolved,
Larry-The-Cow-God-willing, within a year or three) that are placing
higher and higher demands on portage's depsolving engine, as time
passes.
Having lots and lots of packages installed is a huge factor here.
This may be because, by default, portage uses installed packages to
calculate dependencies, resulting in a need to re-cache lots of
stuff... I'm a bit fuzzy on exactly what criteria are used to
determine when this happens, tbh.. that's something I've been meaning
to look into.
Adding something like:
EMERGE_DEFAULT_OPTS=${EMERGE_DEFAULT_OPTS} --backtrack=5
EMERGE_DEFAULT_OPTS=${EMERGE_DEFAULT_OPTS} --complete-graph=n
EMERGE_DEFAULT_OPTS=${EMERGE_DEFAULT_OPTS} --complete-graph-if-new-use=n
EMERGE_DEFAULT_OPTS=${EMERGE_DEFAULT_OPTS} --complete-graph-if-new-ver=n
EMERGE_DEFAULT_OPTS=${EMERGE_DEFAULT_OPTS} --with-bdeps=n
to you /etc/portage/make.conf may help, as may running emerge
--metadata and/or egencache on your repos. after syncing... but...
these are no panacea.
Sometimes emerge -O is the only way to get some things done in any
reasonable time-frame.
It would help if there were some decent way to get some statistics
about where portage is spending all its time (especially, I suspect,
within the bash code, but the python level would also be interesting
to analyse). Anyone know of a good way of doing that?
-gmt
Re: [gentoo-user] Portage performance dropped considerably
No, it's not just you, running emerge -uNDvp world takes slightly over 18 minutes on my laptop (i5 M 430 @ 2.27GHz) - and when there was lot to update I had to wait over 1hr to just get the list of packages. I wonder if there's some profiling tool for portage. Also: time FEATURES=-xattr emerge owncloud -v real6m31.202s user2m42.057s sys 2m1.541s time FEATURES=xattr emerge owncloud -v real30m15.632s user22m44.369s sys 5m30.129s 5 times longer - for something that's essentially copying files. On 26 January 2014 15:35, Nikos Chantziaras rea...@gmail.com wrote: Anyone else noticed this yet? Some portage update seems to have made emerge -uDN @world perform about 10 times slower than before. It used to take seconds, now it takes about 4 minutes only to tell me that there's nothing to update. And it does that every time, even directly in succession and with the caches warm. Is it just me?
Re: [gentoo-user] Portage performance dropped considerably
Am 26.01.2014 15:35, schrieb Nikos Chantziaras: Anyone else noticed this yet? Some portage update seems to have made emerge -uDN @world perform about 10 times slower than before. It used to take seconds, now it takes about 4 minutes only to tell me that there's nothing to update. And it does that every time, even directly in succession and with the caches warm. Is it just me? As a remedy, you can try to use portage with pypy. I've used this setup for half a year and it works well. make.conf: PYTHON_TARGETS=python2_7 python3_3 pypy2_0 /etc/portage/package.keywords: dev-python/pypy virtual/pypy /etc/portage/package.use: sys-apps/portage pypy2_0 /etc/portage/profile/package.use.mask sys-apps/portage -python_targets_pypy2_0 -pypy2_0 I could give you figures for the performance improvement but they are probably not very helpful as I have 289 overlays active. That means portage regularly requires more than a Gig memory for dependency calculation. Downsides: - emerging pypy takes forever and uses a lot of memory - userfetch and userpriv don't work Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Portage performance dropped considerably
On 01/26/2014 05:06 PM, Florian Philipp wrote: Downsides: - emerging pypy takes forever and uses a lot of memory - userfetch and userpriv don't work It also regularly causes segfaults. zmedico/#gentoo-portage hasufell: yeah, I get random segfaults with pypy also (always seems to be in libc iirc)
Re: [gentoo-user] Portage performance dropped considerably
Am 26.01.2014 17:15, schrieb hasufell: On 01/26/2014 05:06 PM, Florian Philipp wrote: Downsides: - emerging pypy takes forever and uses a lot of memory - userfetch and userpriv don't work It also regularly causes segfaults. zmedico/#gentoo-portage hasufell: yeah, I get random segfaults with pypy also (always seems to be in libc iirc) Not on my machine. YMMV. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Portage performance dropped considerably
Nikos Chantziaras rea...@gmail.com wrote: Anyone else noticed this yet? Some portage update seems to have made emerge -uDN @world perform about 10 times slower than before. It used to take seconds, now it takes about 4 minutes only to tell me that there's nothing to update. And it does that every time, even directly in succession and with the caches warm. Is it just me? I have noticed that it did take a lot longer to do --update --deep --backtrack=30 world update last time, where it took a while was just to assemble the list of packages. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
