starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Bug]: 2.3.2 setting max-old-space-size causes java out of memory on raspberry pi / memory restricted containers. (Workaround) #1265

New Issue
Closed
opened 2026-04-24 23:37:52 +02:00 by adam · 6 comments
adam commented 2026-04-24 23:37:52 +02:00
Owner
Copy Link
Copy Source

Originally created by @CoryM on GitHub (Jul 19, 2023).

Describe the issue

Starting docker container with version 2.3.2 causes immediate container shutdown. Running on a raspberry pi 4 2Gb model.

docker log shows java oom (out of memory) error.

-- LOG --
# Fatal javascript OOM in GC during deserialization

-- DockerCompose.yml --

version: "3.7"
services:
  audiobookshelf:
    restart: unless-stopped
    user: 1000:1000
    image: ghcr.io/advplyr/audiobookshelf:2.3.2
    network_mode: "bridge"
    ports:
      - 13378:80
    volumes:
      - /run/media/corym/myhdd/abs/audiobooks:/audiobooks
      - /run/media/corym/myhdd/abs/podcasts:/podcasts
      - /run/media/corym/myhdd/abs/config:/config
      - /run/media/corym/myhdd/abs/metadata:/metadata
    deploy:
      resources:
        limits:
          memory: 1536M
        reservations:
          memory: 256M
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 2
        window: 120s

adding

    environment:
      - NODE_OPTIONS=--max-old-space-size=1024

fixes the issue. It seems to override the environment variable set inside Dockerfile in 2.3.2
also using docker run -e "NODE_OPTIONS=--max-old-space-size=1024" -p 13378:80 docker_audiobookshelf_1

Steps to reproduce the issue

  1. COMPOSE_HTTP_TIMEOUT=120 docker-compose -f audiobookshelf.yml up -d
  2. docker container crashes

Audiobookshelf version

v2.3.2

How are you running audiobookshelf?

Docker

Originally created by @CoryM on GitHub (Jul 19, 2023). ### Describe the issue Starting docker container with version 2.3.2 causes immediate container shutdown. Running on a raspberry pi 4 2Gb model. docker log shows java oom (out of memory) error. -- LOG -- `# Fatal javascript OOM in GC during deserialization` -- DockerCompose.yml -- ``` version: "3.7" services: audiobookshelf: restart: unless-stopped user: 1000:1000 image: ghcr.io/advplyr/audiobookshelf:2.3.2 network_mode: "bridge" ports: - 13378:80 volumes: - /run/media/corym/myhdd/abs/audiobooks:/audiobooks - /run/media/corym/myhdd/abs/podcasts:/podcasts - /run/media/corym/myhdd/abs/config:/config - /run/media/corym/myhdd/abs/metadata:/metadata deploy: resources: limits: memory: 1536M reservations: memory: 256M restart_policy: condition: on-failure delay: 5s max_attempts: 2 window: 120s ``` adding ``` environment: - NODE_OPTIONS=--max-old-space-size=1024 ``` fixes the issue. It seems to override the environment variable set inside Dockerfile in 2.3.2 also using docker run -e "NODE_OPTIONS=--max-old-space-size=1024" -p 13378:80 docker_audiobookshelf_1 ### Steps to reproduce the issue 1. COMPOSE_HTTP_TIMEOUT=120 docker-compose -f audiobookshelf.yml up -d 2. docker container crashes ### Audiobookshelf version v2.3.2 ### How are you running audiobookshelf? Docker
adam added the bug label 2026-04-24 23:37:52 +02:00
adam closed this issue 2026-04-24 23:37:52 +02:00
adam commented 2026-04-24 23:37:53 +02:00
Author
Owner
Copy Link
Copy Source

@petras-sukys commented on GitHub (Jul 19, 2023):

Not sure if this is related, but had similar issue just running on LXC container.

Container had 512Mb ram, 256Mb swap, was working fine on v2.2.23, upgraded directly to v2.3.2, abs started to get killed, since the container was runing out of memory. Increased max memory to 2G, everything started up as expected, with an interesting memory usage patern: 1.3Gb RAM usage for the first ~10 seconds, then falls back to ~400Mb and climbs to ~900Mb over couple of hours and keeps stable then. I understand, that absolute memory usage may depend on library size.

@petras-sukys commented on GitHub (Jul 19, 2023): Not sure if this is related, but had similar issue just running on LXC container. Container had 512Mb ram, 256Mb swap, was working fine on v2.2.23, upgraded directly to v2.3.2, abs started to get killed, since the container was runing out of memory. Increased max memory to 2G, everything started up as expected, with an interesting memory usage patern: 1.3Gb RAM usage for the first ~10 seconds, then falls back to ~400Mb and climbs to ~900Mb over couple of hours and keeps stable then. I understand, that absolute memory usage may depend on library size.
adam commented 2026-04-24 23:37:55 +02:00
Author
Owner
Copy Link
Copy Source

@satiku commented on GitHub (Jul 22, 2023):

I am also getting a similar issue and also add the the '--max-old-space-size=1024 ' flag which helped alleviate the issue for a bit . But my container still crashed if re-scan the library or try and scan a particularity large RSS feed if the swap memory is full .

Container Logs
'''
audiobookshelf_1 | Config /config /metadata
audiobookshelf_1 | [2023-07-22 06:32:57] INFO: === Starting Server ===
audiobookshelf_1 | [2023-07-22 06:32:57] INFO: [Server] Init v2.3.1
audiobookshelf_1 | [2023-07-22 06:32:57] INFO: [Database] Initializing db at "/config/absdatabase.sqlite"
audiobookshelf_1 | [2023-07-22 06:32:57] INFO: [Database] Db connection was successful
audiobookshelf_1 | [2023-07-22 06:32:57] INFO: [Database] Db initialized with models: user, library, libraryFolder, book, podcast, podcastEpisode, libraryItem, mediaProgress, series, bookSeries, author, bookAuthor, collection, collectionBook, playlist, playlistMediaItem, device, playbackSession, feed, feedEpisode, setting
audiobookshelf_1 |
audiobookshelf_1 | <--- Last few GCs --->
audiobookshelf_1 |
audiobookshelf_1 | [1:0x7fc6755f93f0] 39763 ms: Mark-sweep (reduce) 1947.4 (1977.0) -> 1947.4 (1977.0) MB, 110.4 / 0.0 ms (+ 29.4 ms in 2 steps since start of marking, biggest step 29.4 ms, walltime since start of marking 202 ms) (average mu = 0.963, current mu = 0.801)[1:0x7fc6755f93f0] 39874 ms: Mark-sweep (reduce) 1948.8 (1978.4) -> 1948.8 (1978.4) MB, 91.7 / 0.0 ms (average mu = 0.939, current mu = 0.171) allocation failure scavenge might not succeed
audiobookshelf_1 |
audiobookshelf_1 |
audiobookshelf_1 | <--- JS stacktrace --->
audiobookshelf_1 |
audiobookshelf_1 | FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
'''

@satiku commented on GitHub (Jul 22, 2023): I am also getting a similar issue and also add the the '--max-old-space-size=1024 ' flag which helped alleviate the issue for a bit . But my container still crashed if re-scan the library or try and scan a particularity large RSS feed if the swap memory is full . Container Logs ''' audiobookshelf_1 | Config /config /metadata audiobookshelf_1 | [2023-07-22 06:32:57] INFO: === Starting Server === audiobookshelf_1 | [2023-07-22 06:32:57] INFO: [Server] Init v2.3.1 audiobookshelf_1 | [2023-07-22 06:32:57] INFO: [Database] Initializing db at "/config/absdatabase.sqlite" audiobookshelf_1 | [2023-07-22 06:32:57] INFO: [Database] Db connection was successful audiobookshelf_1 | [2023-07-22 06:32:57] INFO: [Database] Db initialized with models: user, library, libraryFolder, book, podcast, podcastEpisode, libraryItem, mediaProgress, series, bookSeries, author, bookAuthor, collection, collectionBook, playlist, playlistMediaItem, device, playbackSession, feed, feedEpisode, setting audiobookshelf_1 | audiobookshelf_1 | <--- Last few GCs ---> audiobookshelf_1 | audiobookshelf_1 | [1:0x7fc6755f93f0] 39763 ms: Mark-sweep (reduce) 1947.4 (1977.0) -> 1947.4 (1977.0) MB, 110.4 / 0.0 ms (+ 29.4 ms in 2 steps since start of marking, biggest step 29.4 ms, walltime since start of marking 202 ms) (average mu = 0.963, current mu = 0.801)[1:0x7fc6755f93f0] 39874 ms: Mark-sweep (reduce) 1948.8 (1978.4) -> 1948.8 (1978.4) MB, 91.7 / 0.0 ms (average mu = 0.939, current mu = 0.171) allocation failure scavenge might not succeed audiobookshelf_1 | audiobookshelf_1 | audiobookshelf_1 | <--- JS stacktrace ---> audiobookshelf_1 | audiobookshelf_1 | FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory '''
adam commented 2026-04-24 23:37:56 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Jul 22, 2023):

@satiku Those logs are from 2.3.1. The latest version is 2.3.3 where I improved performance. If you want to try the :edge docker image I removed that --max-old-space-size from the Dockerfile.

@advplyr commented on GitHub (Jul 22, 2023): @satiku Those logs are from 2.3.1. The latest version is 2.3.3 where I improved performance. If you want to try the `:edge` docker image I removed that `--max-old-space-size` from the Dockerfile.
adam commented 2026-04-24 23:37:56 +02:00
Author
Owner
Copy Link
Copy Source

@satiku commented on GitHub (Jul 23, 2023):

@advplyr thank you for the quick reply I had not realized there had been 2 minor releases since I first encounter the issue. I am now running 2.3.3 and the container is defiantly more stable but I am still running into some minor issues. When I try and add the rss feed for the " stuff you should know" podcast . The container uses up a good chuck of memory and does not add the rss link to the podcast. I have noted the link below . For now this is not terrible since I still have most of episodes from when I was running the previous release and adding the rss link no longer crashes the container permanently , it does cause the container to restart sometimes .

https://omnycontent.com/d/playlist/e73c998e-6e60-432f-8610-ae210140c5b1/A91018A4-EA4F-4130-BF55-AE270180C327/44710ECC-10BB-48D1-93C7-AE270180C33E/podcast.rss

thank you

@satiku commented on GitHub (Jul 23, 2023): @advplyr thank you for the quick reply I had not realized there had been 2 minor releases since I first encounter the issue. I am now running 2.3.3 and the container is defiantly more stable but I am still running into some minor issues. When I try and add the rss feed for the " stuff you should know" podcast . The container uses up a good chuck of memory and does not add the rss link to the podcast. I have noted the link below . For now this is not terrible since I still have most of episodes from when I was running the previous release and adding the rss link no longer crashes the container permanently , it does cause the container to restart sometimes . https://omnycontent.com/d/playlist/e73c998e-6e60-432f-8610-ae210140c5b1/A91018A4-EA4F-4130-BF55-AE270180C327/44710ECC-10BB-48D1-93C7-AE270180C33E/podcast.rss thank you
adam commented 2026-04-24 23:37:57 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Jul 23, 2023):

@satiku Can you share the crash log? I just tested and not able to reproduce that

@advplyr commented on GitHub (Jul 23, 2023): @satiku Can you share the crash log? I just tested and not able to reproduce that
adam commented 2026-04-24 23:37:57 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Sep 13, 2023):

That env variable was removed in the latest releases

@advplyr commented on GitHub (Sep 13, 2023): That env variable was removed in the latest releases
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#1265
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?