Your message dated Tue, 8 Mar 2016 10:28:00 +0000
with message-id <[email protected]>
and subject line Re: aptitude far too big a memory hog
has caused the Debian Bug report #369231,
regarding aptitude far too big a memory hog
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
369231: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=369231
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: aptitude
Version: 0.4.1-1
Severity: important
I read that apt-get is to be deprecated in favour of aptitude, but
unfortunately, if that is to happen, aptitude *must* be made much more
memory lean.
Debian is meant to be able to installed on a small machine with 32MB of
RAM, yet just performing an aptitude upgrade on a machine with 256MB
of ram was taking an inordinate amount of time just to read the
database. The reason being is that it wants to use:
7800 root 18 0 184m 103m 97m D 3.3 41.3 0:26.73 aptitude
during in particular the "Building tag database" phase (although it
was hogging memory what I would call "excessively" before then too.
That is seriously unusable. If I want to add a single package to the
system using aptitude, I can expect to wait half an hour for it to
install on a machine that is only a few years old -- 256MB is *not* a
small amount of RAM.
Compare that to the same phase (asking me whether I want to continue)
in apt-get:
9239 root 17 0 171m 17m 15m S 0.0 6.8 0:02.91 apt-get
Same virtual ram, but it's not actually doing anything with what's
mapped, so it doesn't get read in. Much more acceptable, no?
The number of packages I have installed (it is a desktop system)
appears to be 1580, and /var/lib/dpkg/info disk usage is 47MB (running
unstable). Anything else of relevance?
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15.1
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)
Versions of packages aptitude depends on:
ii apt [libapt-pkg-libc6.3-6-3.1 0.6.44.1 Advanced front-end for dpkg
ii libc6 2.3.6-9 GNU C Library: Shared libraries
ii libgcc1 1:4.1.0-4 GCC support library
ii libncursesw5 5.5-2 Shared libraries for terminal hand
ii libsigc++-2.0-0c2a 2.0.16-3 type-safe Signal Framework for C++
ii libstdc++6 4.1.0-4 The GNU Standard C++ Library v3
Versions of packages aptitude recommends:
pn aptitude-doc-en | aptitude-do <none> (no description available)
-- no debconf information
--- End Message ---
--- Begin Message ---
tags 369231 - moreinfo
stop
2015-11-07 21:09 To Tim Connors:
Improving the performance itself has quite a lot of value, for example
improving start-up times to take fractions of a second. But I think
that things like not using debtags when in command line mode will mostly
benefit start-up times, not memory usage issues.
I worked on some of the issues above lately, like loading debtags only
lazily, which should help with not only memory but also disk and CPU,
specially in old machines.
Contrary to what other bug commenters say, aptitude command line mode
also uses debtags sometimes, for example to match patterns, in the
"show" command, among others.
So, having all of this into account, it doesn't seem to me that the bug
can be classified as "important" by now, and seeing some of the bigger
problems that aptitude accumulated during years of decay, this doesn't
look either high priority or trivial enough to merit spending the time
needed to address this in the near future (at which point, memory usage
will probably be even less relevant).
So I am leaving this open for now for further consideration, but I don't
think that this is going to be addressed soon.
As explained in previous messages, the memory usage comes from libapt in
the more immediate term, but ultimately comes from the huge number of
packages, and specially with the interactive mode of aptitude, it needs
to be accessed all the time.
Adding several distributions at the same time (like testing and
unstable, in the original report) doesn't help, so better avoid this in
machines with memory constraints.
A tradeoff to use more memory overall would be to not read this from
memory structures and re-read them from disk, but:
a) this is probably a bad tradeoff for current machines (with much more
memory, but similarly slow disk access as decades ago)
b) even if it was possible, I don't see anybody worried enough about
this to go and do the necessary changes in libapt and possibly
aptitude
So closing the report now, if it wasn't implemented in the past decade
when resources were more constrained, slim chance now.
Cheers.
--
Manuel A. Fernandez Montecelo <[email protected]>
--- End Message ---
_______________________________________________
Aptitude-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
