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

[Chris Green]

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?


--
Chris Green
·

[Robert Nelson]

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,

--
Robert Nelson
https://rcn-ee.com/

[Chris Green]

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! :-)

--
Chris Green
·

[jonnymo]

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

Jon

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/49sleh-gr3m.ln1%40esprimo.zbmc.eu.

[Robert Nelson]

On Mon, Feb 1, 2021 at 12:10 PM jonnymo <jonn...@gmail.com> wrote:
>
> How do you have your BB connected network wise. Also, what image are you running?

apt search is a cpu-cycle..

[Robert Nelson]

> 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! :-)

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

https://github.com/RobertCNelson/omap-image-builder/commit/58d9d295cfc0e7b435cbe4d6cd71e534fbe3829b

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....

[Chris Green]

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!

--
Chris Green
·

[Chris Green]

jonnymo <jonn...@gmail.com> wrote:
> [-- text/plain, encoding quoted-printable, charset: UTF-8, 98 lines --]

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

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.

--
Chris Green
·

[Dennis Lee Bieber]

On Mon, 1 Feb 2021 18:01:40 +0000, in gmane.comp.hardware.beagleboard.user
Chris Green <cl-RxdK...@public.gmane.org> wrote:

>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.


--
Dennis L Bieber

[jonnymo]

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\212`2\27\331\355\323J"..., 4096) = 4096

read(5, "I\210\363\32\364o$\16[\201]bS`S\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 

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/kfpleh-k7tl.ln1%40esprimo.zbmc.eu.

[Chris Green]

jonnymo <jonn...@gmail.com> wrote:
> [-- text/plain, encoding quoted-printable, charset: UTF-8, 121 lines --]

>
> 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\212`2\27\331\355\323J"...,

> 4096) = 4096*
> *read(5,

> "I\210\363\32\364o$\16[\201]bS`S\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.
>

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.

--
Chris Green
·

[Chris Green]

Chris Green <c...@isbd.net> wrote:
> 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.
>

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




--
Chris Green
·

[Steve Lentz]

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.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/o8sneh-eb5.ln1%40esprimo.zbmc.eu.