mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
Out of Memory #190
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/audiobookshelf#190
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @MisterZakary on GitHub (Jan 29, 2022).
The server is deployed using docker. The standby is normal. Once you listen to the book, the memory occupation is very high, and the web client and Android client cannot be used normally. The relevant information is shown in the picture:
@advplyr commented on GitHub (Jan 29, 2022):
Is it the server or the web client that is out of memory?
@MisterZakary commented on GitHub (Jan 30, 2022):
Web Client.
But I personally think that the web client and Android client can not be used properly because of the server problem. When listening to audio books, Docker shows that the memory consumption of the server can be as high as 4GB.
@MisterZakary commented on GitHub (Jan 30, 2022):
Maybe it's because the book (novel) is too long, it takes 334 hr and 17 min to read, and the total file size is 18GB. Please optimize the super-long audiobook.
@advplyr commented on GitHub (Jan 30, 2022):
If you can monitor the memory usage when playing other audiobooks of various sizes that would help me understand the baseline.
@MisterZakary commented on GitHub (Jan 31, 2022):
This is the memory footprint in different situations:
By splitting the same book into different volumes, the memory footprint is now basically acceptable. Each volume contains 100 files with a total size of 974 MB, playback duration of 34 hr and 11 min, and memory consumption between 1.5GB-2.0GB. However, the line is often disconnected during playback, and Docker looks at the log and shows [ERROR: [Server] clientEmitter-no clients found for user usr_ydsr3872gqnz8n1cnd].
log.zip
@advplyr commented on GitHub (Feb 1, 2022):
That memory usage is way too high for what you are doing.
This may be related to the unstable socket connection you are experiencing.
From your logs it is hard to tell if the socket issues are happening with the web or mobile app. If you can try testing with just the web app that would help. Also, there was a new android app version update that should fix one of the sync issues I noticed you had in the log.
When you restart the server, without opening any clients up, what is the idle memory usage? For me it is 46MB.
If you open the web client after a restart and navigate around without playing an audiobook, do you notice any memory spikes? Try sorting, filtering or making an update.
When you first play an audiobook you should see a spike in memory usage until the transcode has finished. Once the transcode is done you should see the memory usage go back down while you are still streaming.
@Lipown commented on GitHub (Feb 16, 2022):
Hello, any solution here? Basically I was unable to scan the library. I had 2 GB set on VM when docker runs until i set the ram to 4Gigs, oom killer killed all containers after pushing scan library button.
@advplyr commented on GitHub (Feb 16, 2022):
I haven't identified the problem yet, not enough data. What OS are you using and are you using a remote file system for your library?
Do you have how long it took to use that memory after hitting scan? Do you have audio files that are a few GB each?
@newhinton commented on GitHub (Mar 9, 2022):
I have probably the same issue. I am running Audiobookshelf in docker on a Raspberry Pi 4 2GB, and the library is on an attached external drive. Scanning 100 Books eventually crashes the container.
After hitting force rescan, it starts scanning for roughly 3 minutes, then i get the first local cover set message, and roughly after 50 seconds the container shows the restart messages.
i can also see that during scanning the serverload basically skyrockets to 280 and more, and quite a lot of ffprobe processes show up. Each of those roughly uses 10mb of ram and if 200 or more show up they can easily kill a server.
Is there a way to start the docker container with more verbose logging?
Edit:
ps -C ffprobe | wc -lpeaked at 2151 instances. After that it reduced down to 80 and then the server became unresponsive. It seems it didnt crash though, adding 1GB swap seemed to catch the crashing issue, though cpu load is extremely high and ffprobe instances keep stacking up again (before dropping back to more reasonable numbers)
Edit2:Adding 1GB swap let the scan finish. However, it basically renders the pi nearly useless and irresponsive for the duration of the scan.It failed again and just restarts the container
@advplyr commented on GitHub (Apr 24, 2022):
Consolidating issues with the scanner and memory/performance here #444