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

[PR #5168] Fix OOM for large queries/books with many files #4451

New Issue
Open
opened 2026-04-25 00:50:47 +02:00 by adam · 0 comments
adam commented 2026-04-25 00:50:47 +02:00
Owner
Copy Link
Copy Source

📋 Pull Request Information

Original PR: https://github.com/advplyr/audiobookshelf/pull/5168
Author: @Vito0912
Created: 4/5/2026
Status: 🔄 Open

Base: master ← Head: feat/lessMemoryUsage5

📝 Commits (1)

  • e8191b5 move num calculation inside sql

📊 Changes

3 files changed (+70 additions, -13 deletions)

View changed files

📝 server/models/Book.js (+19 -6)
📝 server/models/LibraryItem.js (+5 -6)
📝 server/utils/queries/seriesFilters.js (+46 -1)

📄 Description

Brief summary

Fix OOM [when sorting series by book count descending (see the discord issue below) - But this probably is just a side effect as this causes more books to be loaded then normally when the biggger series are more spread out] by computing the aggregates in SQL and avoiding large JSON arrays in Node

Which issue is fixed?

https://discord.com/channels/942908292873723984/954760207131615264/1487727986760351746

In-depth Description

Counts and sizes (tracks, audio files, chapters, libraryFiles, media size) are computed via DB JSON functions and exposed as computed attributes. Includes for book/libraryItem are limited to needed fields and serializers read computed values with fallbacks, so results match previous output but use far less Node heap.

How have you tested this?

Requested the endpoint (limit=1, desc=1) before/after
before triggered OOM, after returns the same minified fields without OOM and with similar payload contents.

The speed also is ~ the same. There is a lot of fluctuation though and in general it might be a bit slower for smaller payloads. The dataset I tested this on, which was provided to me, had a lot of files per book and a lot of books per series in general. So this only helps in these cases. Maybe there are some better optimizations, but as this is just a json blob, without normalization I don't think there can be done much much more

Some before after (take with a grain of salt)

Before After
image image

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/advplyr/audiobookshelf/pull/5168 **Author:** [@Vito0912](https://github.com/Vito0912) **Created:** 4/5/2026 **Status:** 🔄 Open **Base:** `master` ← **Head:** `feat/lessMemoryUsage5` --- ### 📝 Commits (1) - [`e8191b5`](https://github.com/advplyr/audiobookshelf/commit/e8191b503de60bf58e98f1228b7168b87705628c) move num calculation inside sql ### 📊 Changes **3 files changed** (+70 additions, -13 deletions) <details> <summary>View changed files</summary> 📝 `server/models/Book.js` (+19 -6) 📝 `server/models/LibraryItem.js` (+5 -6) 📝 `server/utils/queries/seriesFilters.js` (+46 -1) </details> ### 📄 Description <!-- For Work In Progress Pull Requests, please use the Draft PR feature, see https://github.blog/2019-02-14-introducing-draft-pull-requests/ for further details. If you do not follow this template, the PR may be closed without review. Please ensure all checks pass. If you are a new contributor, the workflows will need to be manually approved before they run. --> ## Brief summary Fix OOM [when sorting series by book count descending (see the discord issue below) - But this probably is just a side effect as this causes more books to be loaded then normally when the biggger series are more spread out] by computing the aggregates in SQL and avoiding large JSON arrays in Node ## Which issue is fixed? https://discord.com/channels/942908292873723984/954760207131615264/1487727986760351746 ## In-depth Description Counts and sizes (tracks, audio files, chapters, libraryFiles, media size) are computed via DB JSON functions and exposed as computed attributes. Includes for `book`/`libraryItem` are limited to needed fields and serializers read computed values with fallbacks, so results match previous output but use far less Node heap. ## How have you tested this? Requested the endpoint (limit=1, desc=1) before/after before triggered OOM, after returns the same minified fields without OOM and with similar payload contents. The speed also is ~ the same. There is a lot of fluctuation though and in general it might be a bit slower for smaller payloads. The dataset I tested this on, which was provided to me, had a lot of files per book and a lot of books per series in general. So this only helps in these cases. Maybe there are some better optimizations, but as this is just a json blob, without normalization I don't think there can be done much much more Some before after (take with a grain of salt) | Before | After | |--------|--------| | <img width="83" height="732" alt="image" src="https://github.com/user-attachments/assets/5bef8d66-5267-4c28-b3c0-182471815bca" /> | <img width="83" height="732" alt="image" src="https://github.com/user-attachments/assets/6b087161-34a3-4374-be1c-5d54612d3a26" /> | --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
adam added the pull-request label 2026-04-25 00:50:47 +02:00
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 pull-request
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#4451
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?