Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create RAM.md #94

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft

Create RAM.md #94

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
776b12d
Create RAM.md
TechnicJelle Oct 17, 2024
df3491d
RAM guide: Improve intro
TechnicJelle Dec 7, 2024
4d302fb
RAM guide: slightly edited the intro some more
TechnicJelle Dec 7, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 50 additions & 0 deletions community/RAM.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
---
layout: page
title: BlueMap and RAM
parent: Community Guides
nav_order: 16
---

# BlueMap and RAM
{: .no_toc }

Do not be alarmed if you notice that BlueMap seems to be using a lot of RAM.
This is actually perfectly normal and should not be an actual problem.

There are multiple things that contribute to this effect:

### 1. Unused RAM
BlueMap is using **unused** heap-space (RAM) to cache some things
like e.g. chunk-data and resources to improve performance.
But as soon as your JVM (your server) needs this cache-space somewhere else, it can do so!
BlueMap is not hard-reserving that space, so it can't cause an OOM because of this.
*(Technically this is done using a [SoftValue-Cache](<https://www.baeldung.com/java-caching-caffeine#3-reference-based-eviction>))*
After all, it is always said that unused RAM is wasted RAM.

### 2. Garbage Collection
RAM/Heap management in your JVM is done using a Garbage Collector.
Your JVM runs this GC in intervals to free up heap-space that is no-longer used.
If you have a big heap of multiple GBs, depending on your GC-configuration,
it can wait for a long time until it decides to run the GC and free some space.
This has the effect that your RAM-Usage will keep climbing until the GC is ran.
**Or:** until you restart the server.

So if you remove BlueMap to prove that it is using a lot of RAM,
Copy link
Member Author

Choose a reason for hiding this comment

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

Not entirely happy with this sentence yet. It is very long. Could use some splitting up.

what you actually did is you restarted the server,
resetting your heap that has risen to a higher amount
and now it looks like you have much less heap-usage,
but all it actually is just a freshly cleaned heap
which will rise again if the server runs for a while,
even if BlueMap is removed now.

## Conclusion
If you are having OOM errors, it is usually unlikely that BlueMap is causing them.
In fact, BlueMap has been tested to run fine with only 500MB of RAM!
However, if you still believe it's BlueMap causing your OOM,
then please use the Java startup flag `-XX:+HeapDumpOnOutOfMemoryError`
to create a heap-dump the next time an OOM occurs,
and send it in the [Discord](https://bluecolo.red/map-discord) in some way.
(Heap-dumps are very big unfortunately, so you may need to use a cloud service)
We are willing to analyse that heap-dump to check what actually has caused your OOM
and if it really was BlueMap :)