Skip to content

Conversation

@PartiallyUntyped
Copy link
Contributor

Added FAQ section addressing memory leak concerns, including explanations and recommendations.

🔏 By submitting this pull request

  • I confirm that my contribution is made under the terms of the Apache 2.0 license.

Added FAQ section addressing memory leak concerns, including explanations and recommendations.
Copy link
Collaborator

@jlizen jlizen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great addition, thanks for writing this!

Looks like it didn't actually. merge, FYI, since our permissions were scrambled in the github org move. Might be worth reopening to not lose track.


<img width="2036" height="1177" alt="image" src="https://github.com/user-attachments/assets/778e2857-8c1a-49f4-968b-47739f445858" />

**What can I do about it?**
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth talking about optimizing serde to reduce allocations via eg #[serde(borrow)] and Cow<'json, str> and other micro optimizations? This is a known issue with serde that you can work around somewhat.

An article is actually currently making the rounds about similar workflows: https://sander.saares.eu/2025/10/15/memory-allocation-is-the-root-of-all-evil-part-2-rust/


**What can I do about it?**

You can experiment with different allocators like `jemalloc`, along with different environment flags. For example setting a single arena for `glibc` via `MALLOC_ARENA_MAX=1`. In `jemalloc` enabling a background thread with a short decay for dirty memory sweeps will induce more frequent sweeps.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I generally recommend mimalloc instead these days, since jemalloc is unmaintained and mimalloc has been showing better results in many scenarios anyway. Though we could mention both too.


We recommend that you don’t mess with your allocator settings until you start seeing degradation / getting closer to max memory for your function.

Finally, we note that sandboxes have a finite lifespan, and will recycle over time and as needed, thus ameliorating the accumulated fragmentation.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: ameliorating -> garbage collecting maybe?


The metric `used_memory_max` increases because the allocator keeps requesting more memory pages from the operating system because memory gets fragmented and we end up with lots of small objects allocated in non-contiguous blocks. This means that we may have sufficient free memory to handle the request, but we don’t necessarily have enough contiguous memory marked as “safely deallocated” to be able to reuse it.

The culprit of these allocations according to our investigation is serde::deserialize
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: needs a period or colon

@jlizen
Copy link
Collaborator

jlizen commented Nov 14, 2025

As a side concern - this might be a bit much detail to go inline in the README? What do you think about a standalone .md for it and instead just a link from the main README?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants