apt on BBB *very* slow, anyone else noticed?

GoogleGroups
1

I have recently done a clean install of Debian on a BBB and it feels
*very* slow, especially when running apt. Even 'apt search' just
crawls along at times.

Has something changed to cause this or have I just got used to fast
hardware and forgotten what a BBB is like, or what?

Here's a timing of a search:-

    chris@beaglebone$ time apt search vile
    Sorting... Done
    Full Text Search... Done

    [snip results]

    real 4m4.103s
    user 3m55.675s
    sys 0m7.152s

Over four minutes for a simple search seems rather slow.

I tried the same on an old Raspberry Pi :-

    chris@dns$ time apt search vile
    Sorting... Done
    Full Text Search... Done

    [snip results]

    real 0m8.512s
    user 0m8.228s
    sys 0m0.285s

Just eight seconds, much more reasonable, so what's happened to the BBB?

2

debian@bbb-pwr01-ser09:~$ time apt search vile
Sorting... Done
Full Text Search... Done
bubblewrap/stable 0.3.1-4 armhf
  setuid wrapper for unprivileged chroot and namespace manipulation

zulupolkit/stable 5.4.0-3 armhf
  handler the polkit privileges

real 0m15.199s
user 0m13.600s
sys 0m1.135s

model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]

Regards,

3

That seems much more reasonable, I wonder what's up with mine.

Does running of an SD card rather than the EMMC slow things down a
lot? I have tried a bigger, newer SD card to see if it speeded
things up but it doesn't seem to have had much effect.

Anyway at least it's not me imagining things! :slight_smile:

4

How do you have your BB connected network wise. Also, what image are you running?

Jon

5

apt search is a cpu-cycle..

Regards,

6

That seems much more reasonable, I wonder what's up with mine.

Does running of an SD card rather than the EMMC slow things down a
lot? I have tried a bigger, newer SD card to see if it speeded
things up but it doesn't seem to have had much effect.

Anyway at least it's not me imagining things! :slight_smile:

Here's a recent change on this, pretty much we dropped our custom
thing, and just copied the PI's configuration:

you can run

sudo rm /etc/apt/apt.conf.d/02compress-indexes

Disable PDiff's..

echo 'Acquire::PDiffs "0";' > /tmp/02-no-pdiffs
sudo mv /tmp/02-no-pdiffs /etc/apt/apt.conf.d/02-no-pdiffs
sudo chown root:root /etc/apt/apt.conf.d/02-no-pdiffs

Then run:

sudo apt update

and you'll see about a 100MB's of free space removed.. But it's faster....

Regards,

7

It's on the same LAN (using ethernet, not USB) as the Raspberry Pi
whose speed I quoted above. However I don't think the 'apt search'
uses the LAN or internet at all.

It's a 'console' image, from the latest April 2020 build.

8

Not much! I've done all the above and it feels just as bad. The 'apt
search' is odd, it whizzes through to 68% or 69% and then runs like
treacle. Here's the time :-

    root@beaglebone:~# time apt search vile
    Sorting... Done
    Full Text Search... Done
    bubblewrap/stable 0.3.1-4 armhf
      setuid wrapper for unprivileged chroot and namespace manipulation

    [snip]

    real 3m59.631s
    user 3m52.864s
    sys 0m5.447s

Well, it's four or five seconds quicker!

9

Does running of an SD card rather than the EMMC slow things down a
lot? I have tried a bigger, newer SD card to see if it speeded
things up but it doesn't seem to have had much effect.

  Depending upon the SD card -- yes!

  Note that "Class 10" cards are speed rated for STREAMING a single file
to/from a freshly formatted card (eg: video). "Class 2/4/6" cards are rated
for multiple small file writes&reads with fragmentation (eg: still photo
camera with some images deleted). Also note that all such are based upon
FAT file system -- not a journaling system.

  Some card makers of "Class 10" cards take advantage of this, and fit
controllers on the card that can only track TWO "open" "allocation units"
-- the FAT table, and the data file. Every time the filesystem has to open
another file (and that happens a lot with journals -- write new contents
somewhere, write metadata to journal, sometime later wipe out original
metadata, followed by writing journal metadata and deleting journal) it has
to obtain a new allocation unit -- this involves closing and flushing the
current allocation unit to the memory, finding and erasing a free
allocation unit (erase is slow, as it has to set every bit in the unit to
"1" -- writing can only toggle a "1" bit to a "0"), then copying unchanged
data that might be in an old allocation unit before writing new data to
that unit.

  Better cards will support 4 to 6 simultaneous open allocation units,
meaning one can be updating multiple files in parallel without forcing
erase cycles and copying partial units around.

  From a post I made last March

From a post (of mine) on the R-Pi group... Running the "Raspberry Pi
Dramble microSD benchmarks".
curl
https://raw.githubusercontent.com/geerlingguy/raspberry-pi-dramble/master/setup/benchmarks/microsd-benchmarks.sh

benchmark.sh

"bdr-" is the "buffered disk read" from hdparm
"dd-" are, well, "dd"
The rest are "iozone" results.

The BBB has
  SanDisk Edge 8GB Class 4 HC I8227DTJLT009
Not sure of the eMMC version
The R-Pi3B+ has
  Kingston 16GB Class 10 HC I U1 SDC10G2/16GB N0581-002.A00LF

metric BBB (SD) RPi3B+ eMMC
bdr-MB 21.74 21.97 hdparm did not run (tried to access SD)*
dd-sec 89.4367 67.4917 63.8932
dd-MB 4.7 6.2 6.6
write 1652 250 1814
rewrite 2306 237 1888
read 6371 5814 5039
reread 6375 5798 5038
ranread 5364 5138 3562
ranwrite 1157 234 395

The Class 4 SanDisk, in the 1GHz single-core BBB readily beat the Class
10 Kingston in a 1.4GHz quad-core R-Pi3B+ in any meaningful test (the
Kingston only won out on the "bdr" and "dd" test cases, and the BBB eMMC
beat it on the "dd" test). {Note: I just reran on the SD card, and
"write"/"rewrite" only showed 405/284, which still beats the Class 10 --
suspect if I redid the test it might improve as the SD card may have
remnants getting reused)

  The SanDisk Class 4 was easily 8 times faster than the Kingston Class
10 for regular write, rewrite, and random write, and was also faster (if
not as much) for read/reread/random read.

10

On my Beaglebone AI via Wi-Fi, I got this:

debian@beaglebone:~$ time apt search vile
Sorting… Done
Full Text Search… Done

real 2m10.764s
user 2m5.185s
sys 0m3.954s

Raspberry Pi 4 Wi-Fi:

real 0m2.637s
user 0m2.349s
sys 0m0.288s

Running ‘strace apt search vile’ on the BBAI, it appears to be stuck in some sort of read loop which is taking all the time.
.
.
.

read(5, “\344\255\246h4F\314\330y\241\250D2\350i3\0044H\253\16\250\306\364\2122\27\331\355\323J"..., 4096) = 4096** **read(5, "I\210\363\32\364o$\16[\201]bSS\357\3620\372QC\202\245b\271\300\312|\311Q\355\27”…, 4096) = 4096
read(5, " n\206Z\225\271\264\35\r,\203\331f\5;\260k\200p\314\16\355\222\204\332A/\226\267\237\277\33"…, 4096) = 4096
read(5, “\250\235\303\34B\216GE\2<\266\275P\262\210]`0{\222\306\270p\245\214\310\6\33\231\3343\33”…, 4096) = 3200
read(5, “”, 4096) = 0
) = 26ext Search… Donearch… Done\r", 26

On the RasPi, it runs through quite quickly and done.

Cheers,

Jon

11

That's interesting, it looks as if there is some sort of bug/oddity on
the BBB then. It does seem to affect some other things as well, my
BBB feels a lot slower in general than previous incarnations were.
Maybe I'll try an older Debian and see if it acts the same.

12

The problem isn't unique to the BBB/Debian, I've found quite a few
other people with similar issues where parts of apt take a very long
time.

The time taken seems to relate to how many hits there are in the
search! If you search for something that doesn't exist it takes (on
my BBB) about 30 seconds:-

    chris@beaglebone$ time apt search xyzabc
    Sorting... Done
    Full Text Search... Done

    real 0m27.532s
    user 0m26.315s
    sys 0m1.035s

Searching for something that has three hits takes longer:-

    chris@beaglebone$ time apt search xvile
    Sorting... Done
    Full Text Search... Done
    vile-common/stable,now 9.8t-1 all [installed,automatic]
      VI Like Emacs - support files for vile/xvile

    vile-filters/stable,now 9.8t-1 armhf [installed]
      VI Like Emacs - highlighting filters for vile/xvile

    xvile/stable 9.8t-1 armhf
      VI Like Emacs - vi work-alike (X11)

    real 1m2.063s
    user 0m59.874s
    sys 0m1.862s

Searching for just 'vile' produces quite a lot of hits because there's quite a few packages
with the word 'privilege' in them, so it takes around four minutes.

A workaround is to use 'apt-cache search' instead:-

    chris@beaglebone$ time apt-cache search vile
    bubblewrap - setuid wrapper for unprivileged chroot and namespace manipulation
    calife - Provides super user privileges to specific users
    chiark-really - really - a tool for gaining privilege (simple, realistic sudo)
    cups-pk-helper - PolicyKit helper to configure cups with fine-grained privileges
    fakeroot - tool for simulating superuser privileges
    libfakeroot - tool for simulating superuser privileges - shared libraries
    gssproxy - Privilege separation daemon for GSSAPI
    libkf5su5 - Integration with su for elevated privileges.
    lacme - ACME client written with process isolation and minimal privileges in mind
    libprivileges-drop-perl - module to make it simple to drop all privileges
    libutempter-dev - privileged helper for utmp/wtmp updates (development)
    libutempter0 - privileged helper for utmp/wtmp updates (runtime)
    policykit-1 - framework for managing administrative policies and privileges
    privbind - Allow unprivileged apps to bind to a privileged port
    libpseudo - advanced tool for simulating superuser privileges
    pseudo - advanced tool for simulating superuser privileges
    python-oslo.privsep - OpenStack library for privilege separation - Python 2.7
    python-oslo.privsep-doc - OpenStack library for privilege separation - doc
    python3-oslo.privsep - OpenStack library for privilege separation - Python 3.x
    slirp4netns - User-mode networking for unprivileged network namespaces
    sudo - Provide limited super user privileges to specific users
    sudo-ldap - Provide limited super user privileges to specific users
    vile - VI Like Emacs - vi work-alike
    vile-common - VI Like Emacs - support files for vile/xvile
    vile-filters - VI Like Emacs - highlighting filters for vile/xvile
    xvile - VI Like Emacs - vi work-alike (X11)
    weborf - Fast and small webserver meant to be run without root privileges
    libyubikey-udev - udev rules for unprivileged access to YubiKeys
    zulupolkit - handler the polkit privileges

    real 0m21.826s
    user 0m20.697s
    sys 0m0.944s
    chris@beaglebone$

That's not affected by the number of hits:-

    chris@beaglebone$ time apt-cache search xvile
    vile-common - VI Like Emacs - support files for vile/xvile
    vile-filters - VI Like Emacs - highlighting filters for vile/xvile
    xvile - VI Like Emacs - vi work-alike (X11)

    real 0m21.663s
    user 0m20.614s
    sys 0m0.924s

13

Mine runs fast when there’s nothing to be found:

debian@beaglebone:/var/lib/cloud9$ time apt search abcxyz
Sorting… Done
Full Text Search… Done

real 0m11.625s
user 0m10.423s
sys 0m0.482s

But slower when it does get results:

debian@beaglebone:/var/lib/cloud9$ time apt search vile
Sorting… Done
Full Text Search… Done
bubblewrap/stable 0.3.1-4 armhf
setuid wrapper for unprivileged chroot and namespace manipulation

calife/stable 1:3.0.1-5 armhf
Provides super user privileges to specific users

<list of about 20 more results omitted>

real 1m20.150s
user 1m16.055s
sys 0m2.485s

Although no where near as long as OP.