Skip to content

Commit 776b12d

Browse files
authored
Create RAM.md
1 parent 06f5069 commit 776b12d

File tree

1 file changed

+50
-0
lines changed

1 file changed

+50
-0
lines changed

community/RAM.md

Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
1+
---
2+
layout: page
3+
title: BlueMap and RAM
4+
parent: Community Guides
5+
nav_order: 16
6+
---
7+
8+
# BlueMap and RAM
9+
{: .no_toc }
10+
11+
Do not be alarmed if you notice that BlueMap seems to be using a lot of RAM.
12+
This is actually perfectly normal and should not be an actual problem.
13+
14+
There are multiple things that contribute to this effect:
15+
16+
### 1. Unused RAM
17+
BlueMap is using **unused** heap-space (RAM) to cache some things
18+
like e.g. chunk-data and resources to improve performance.
19+
But as soon as your JVM (your server) needs this cache-space somewhere else, it can do so!
20+
BlueMap is not hard-reserving that space, so it can't cause an OOM because of this.
21+
*(Technically this is done using a [SoftValue-Cache](<https://www.baeldung.com/java-caching-caffeine#3-reference-based-eviction>))*
22+
After all, it is always said that unused RAM is wasted RAM.
23+
24+
### 2. Garbage Collection
25+
RAM/Heap management in your JVM is done using a Garbage Collector.
26+
Your JVM runs this GC in intervals to free up heap-space that is no-longer used.
27+
If you have a big heap of multiple GBs, depending on your GC-configuration,
28+
it can wait for a long time until it decides to run the GC and free some space.
29+
This has the effect that your RAM-Usage will keep climbing until the GC is ran.
30+
**Or:** until you restart the server.
31+
32+
So if you remove BlueMap to prove that it is using a lot of RAM,
33+
what you actually did is you restarted the server,
34+
resetting your heap that has risen to a higher amount
35+
and now it looks like you have much less heap-usage,
36+
but all it actually is just a freshly cleaned heap
37+
which will rise again if the server runs for a while,
38+
even if BlueMap is removed now.
39+
40+
## Conclusion
41+
If you are having OOM errors, it is usually unlikely that BlueMap is causing them.
42+
In fact, BlueMap has been tested to run fine with only 500MB of RAM!
43+
However, if you still believe it's BlueMap causing your OOM,
44+
then please use the Java startup flag `-XX:+HeapDumpOnOutOfMemoryError`
45+
to create a heap-dump the next time an OOM occurs,
46+
and send it in the [Discord](https://bluecolo.red/map-discord) in some way.
47+
(Heap-dumps are very big unfortunately, so you may need to use a cloud service)
48+
We are willing to analyse that heap-dump to check what actually has caused your OOM
49+
and if it really was BlueMap :)
50+

0 commit comments

Comments
 (0)