parse-community / parse-community/parse-server
FSAdapter raises RAM consumption after access to file
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 21.4k
- Forks
- 4.8k
- Avg merge
- 7h 45m
- Merged PRs (30d)
- 11
Description
New Issue Checklist
- I am not disclosing a vulnerability.
- I am not just asking a question.
- I have searched through existing issues.
- I can reproduce the issue with the latest version of Parse Server.
Issue Description
When I use FSAdapter and try to fetch multiple files using Parse.File.url({forceSecure: true}), I`m facing growing of RAM consumption up to 2-2.5 times on my server
Steps to reproduce
The simplest way to reproduce:
- Start express app with ParseServer
- Check up RAM consumption as baseline
- Record the OGG audio file, upload it using Parse to the server
- Start playing in
<audio>element in html or any other stream player - Check up RAM consumption - level 1
- Stop playing and destruct player to free up link
- Check up RAM consumption - level 2
Actual Outcome
RAM consumption: baseline < level 1 <= level 2. In my case level 2 = level 1 = 2.5x baseline
Expected Outcome
RAM consumption: baseline < level 1 > level 2. I'd like to have 1.5x level 2 = level 1 = 1.5x baseline
Environment
Server
- Parse Server version:
5.5.3 - Operating system:
Ubuntu 20.04 - Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc):
Local
Database
- System (MongoDB or Postgres):
MongoDB - Database version:
6.0.3 - Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc):
Local
Client
- SDK (iOS, Android, JavaScript, PHP, Unity, etc):
JavaScript - SDK version:
4.1.0
Logs
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the FSAdapter path exercised by Parse.File.url({forceSecure: true}) and reproduce the listed upload, playback, and player-destruction steps while measuring baseline, level 1, and level 2 memory. The issue is resolved when memory after playback returns below the playback peak instead of remaining at the elevated level.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, nodejs
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100