Unexpected high CPU usage and poor performance on Raspberry Pi 4

[markmcnaughton]

Expected Behavior

• app should start in a reasonable time
• after start the UI should be responsive
• client connections should be responsive
• CPU load should not be excessive
• CPU usage should be even across the CPU cores (not sure if this is possible)

Current Behavior

• app takes up to 18 minutes to start
• a simple operation such as the administrator selecting "settings", maxes out a single thread on the CPU for quite a while until the page opens
• UI is frustrating to use because you have a wait a minute or two after selecting any item
• client streaming only works occasionally in my testing.
• I'm not experience anything similar to this in other docker containers such as Navidrome

Steps to Reproduce

• start the container on a Raspberry Pi 4 using docker-compose
• this issue is occurring with only 11 audiobooks in the library

Environment

• Raspberry Pi 4 4GB arm7l
• Arch Linux Arm 5.15.79-2
• Docker 20.10.21
• Docker Compose 2.12.2

Docker Compose File

---

version: "2.1" services: booksonic-air: image: lscr.io/linuxserver/booksonic-air:latest container_name: booksonic-air environment:

• PUID=1000
• PGID=1000
• TZ=Africa/Johannesburg volumes:
• /opt/booksonic-air:/config
• /media/data/audiobooks:/audiobooks ports:
• 4040:4040 restart: unless-stopped

Logs logs.txt

Screnshots

[github-actions[bot]]

Thanks for opening your first issue here! Be sure to follow the bug or feature issue templates!

[srd424]

Same as https://github.com/linuxserver/docker-booksonic-air/issues/11 maybe?

[markmcnaughton]

Same as #11 maybe?

Thank you for the reply, I'm really excited to use this software.

It could be related, however this is a 64 bit Linux image. This is expected to work correctly. The service is not usable on the fastest Pi available with all software updated.

This is not only an issue with start time, the interface and streaming experience is not viable currently.

If you'd like me to test anything, or even if you'd want to contact me for a demo / troubleshooting session. I'm willing to help.

[srd424]

Ah, OK. Might be worth checking what JVM variant is being used in the latest builds now? Actually, might also be worth checking that docker is pulling the right architecture.

Ongoing performance would likely be affected be the issues in #11 too, I just don't think I got that far in my testing

BTW, I'm not affiliated with either booksonic air or linuxserver.io, I just happened to hit similar problems!

[markmcnaughton]

Ah, OK. Might be worth checking what JVM variant is being used in the latest builds now? Actually, might also be worth checking that docker is pulling the right architecture.

Ongoing performance would likely be affected be the issues in #11 too, I just don't think I got that far in my testing

BTW, I'm not affiliated with either booksonic air or linuxserver.io, I just happened to hit similar problems!

Well thanks for the help.

I'm seeing in the logs: Java: 1.8.0_345

I haven't seen a simple method to determine the containers architecture. I assumed it wouldn't start with the incorrect architecture.

I'll try and force the architecture now and see if it makes a difference.

[markmcnaughton]

Ah, OK. Might be worth checking what JVM variant is being used in the latest builds now? Actually, might also be worth checking that docker is pulling the right architecture.

Ongoing performance would likely be affected be the issues in #11 too, I just don't think I got that far in my testing

BTW, I'm not affiliated with either booksonic air or linuxserver.io, I just happened to hit similar problems!

My apologies, I was mistaken. the image I'm running is arm32v7. The arm64v8 won't start as the architecture is arm7l.

So it appears to be the same issue.

This is the current Java version

openjdk version "1.8.0_345" OpenJDK Runtime Environment (IcedTea 3.24.0) (Alpine 8.345.01-r0) OpenJDK Zero VM (build 25.345-b01, interpreted mode)

[thespad]

Unfortunately, the only practical fix for this at the moment would involve running a completely separate build for armhf and that's not something we are willing to support. There's a good chance that at some point in the near future the armhf version of the image will have to be retired entirely.

Please see our statement regarding our support position for armhf going forward https://www.linuxserver.io/blog/end-of-an-arch

[markmcnaughton]

Unfortunately, the only practical fix for this at the moment would involve running a completely separate build for armhf and that's not something we are willing to support. There's a good chance that at some point in the near future the armhf version of the image will have to be retired entirely.

Please see our statement regarding our support position for armhf going forward https://www.linuxserver.io/blog/end-of-an-arch

thank you, it makes sense to re-install the operating system with arm64v8

Thank you for the assistance.