Speed of aptitude on NSLU2
Kurt Pruenner wrote:
> Sorry to barge into this conversation, but I was wondering if you
> maybe could share a few tips about how to configure aptitude on an
> NSLU2 so it's not unbearably slow.
>
> As it is, it takes several minutes for me to start (i.e. until I can
> actually work with it) and moving the cursor around the list takes
> about a second per line... :(
(starting new thread on this, from "Reinstalling debian on n2100".)
That's interesting. aptitude on my slug is annoyingly rather slow, but
the slow parts for me are:
* building the dependency tree
* reading & writing extended state info
* building tag database (wish I could get rid of that - an option?)
* building view
Once I have the view, the response is quite acceptable:
* latency of at most tenths of a second in moving from line to line
* very acceptable response to opening a category ("[") and to "Enter" to
bring up details on a package
* fast closing of "tabs ("q")
So the good news is that I think the response can be acceptable:
we have to determine what are the differences between your setup and
mine. Being reasonably systematic about this, the differences could be:
(1) in the basic hardware and software: unlikely, because I think all
NSLU2s are much the same (?), and we can come back to the differences
between debian/ubuntu versions and versions of aptitude: experience
suggests not much difference here;
(2) in the extent to, and way in, which ram is being used: this is my
best guess for gain: see below for investigations;
(3) in the disks: spinning metal? flash? swap? layout? (see below)
(4) in the network connection (and ssh)
(5) in the client being used (in my experience kde, and to a lesser
extent gnome, adds considerable overhead which is particularly
noticeable on a slower client machine: I get my good NSLU2/aptitude
behaviour on a number of fast clients with gnome, or slower ones with
xfce4 or similar).
Let's pursue the ram idea. My best guess is that your slug is using
ram to do other ("unnecessary") things, and this is leaving too little
ram for aptitude's needs. This leads to excessive swapping
("thrashing"), and this is a classic cause of behaviours like those you
describe. Start by using free. For me, without aptitude running, I
get:
-----------------------
bari@slug0:~$ free
total used free shared buffers cached
Mem: 29988 23192 6796 0 312 10560
-/+ buffers/cache: 12320 17668
Swap: 1992040 35376 1956664
-----------------------
and with aptitude:
-----------------------
bari@slug0:~$ free
total used free shared buffers cached
Mem: 29988 28568 1420 0 340 9456
-/+ buffers/cache: 18772 11216
Swap: 1992040 46504 1945536
-----------------------
So you'll see that aptitude can "steal enough" space from the buffers
& cache. NB the figures given by free do vary quite a lot, so use them
only "impressionistically": but if you see a small number under "free"
in the "-/+ buffers/cache" line, that's definitely an alarm sign.
If this looks promising (or even if not), now get to know "top" and try
to work out what (with and without aptitude running) is taking up ram
(and maybe cpu%). top has a lot of flaws, but it's valuable: use the
hotkeys to rank the lines descending by mem% (I think ">") and see
what's hogging ram.
Now take a look at your /etc/rc2.d (assuming your runlevel is 2). Are
you starting up a lot of services you don't actually need? I should
add that for me, aptitude is ok as above while my slug acts as a file
server, UPnP music server and (lig)http server and a few other things,
so I'm not saying it has to be idling. One of my daughters has one
running apache2 and a complete mail spam-filtering system, so there's a
lot of potential a long as the apps are not cpu or ram intensive.
In my experience, exim is a hog, so unless you really need it,
uninstall it or disable it (see man update-rc.d or probably better, do
it manually by the S20 -> K80 etc method). nfs-common and samba are
other targets for disabling: see the massively helpful
http://www.nslu2-linux.org/wiki/Debian/FAQ
http://www.cyrius.com/debian/nslu2/reducing-memory.html
I actually spent quite a bit of effort finding out what services were
writing to disk, to minimise power use by keeping the disks spun down
unless really needed: I used find with options and a few experiments;
but you may not need to go that far.
That's a start on the ram idea, my best guess. Briefly on the other
matters:
(3) I have almost all my rootfs on a 2GB usb flash drive, with two big
usb-hds (as a RAID1 pair) mainly attached as /var (with a symlink
from /home/bari/data to /var/local/data to store all data). This is
pretty efficient, and undoubtedly having most of /
(especially /bin /sbin /usr/sbin and /usr/bin) on flash speeds things
up. What is your swap setup? (I do use hd for mine.)
(4) Are you sure that your network latency is low? Network bottlenecks
can make remote apps seem sluggish (no pun intended).
(5) See comments above on kde and gnome. What's your client for
viewing aptitude on the NSLU2? Personally, I would probably avoid
konsole.
That's a bit to be going on with. Do come back if you need more,
preferably with some more details about your setup.
Good luck!
Barry
Reply to: