Closed ColdDev closed 1 month ago
server panel is unlikely to be supported. and try to use Process Hacker to show the mem leak
server panel is unlikely to be supported. and try to use Process Hacker to show the mem leak
I can't exactly get Process Hacker inside of the server, because the server panel utilizes Docker containers, and is also Linux based. I have tested other forks of Spigot and this slowly rising memory usage is not present, which leads me to believe this is in some way related to BurritoSpigot.
Burrito's memory usage is always below 1024mb with 30 plugins, no players and running for 24+ hours on my laptop. I'm using zulu jdk8. what jdk did u use and make sure use aikar's jvm flag
Burrito's memory usage is always below 1024mb with 30 plugins, no players and running for 24+ hours on my laptop. I'm using zulu jdk8. what jdk did u use and make sure use aikar's jvm flag
Aikar's JVM flags do not resolve the issue - during a 24-hour long-term test I had standard Aikar's flags applied, minus the AlwaysPreFetch flag, and memory usage was still rising.
I'm using the Pterodactyl-provided Java version: ghcr.io/pterodactyl/yolks:java_8
now mine server was running for almost 4 days. using Clear Lagg plugin, I've found the memory leak could up to 1400 mb then gc to 600mb(no player). u can use a plugin to track ur memory usage and send here. and u can test on Taco/Paper, it might not a burrito bug
now mine server was running for almost 4 days. using Clear Lagg plugin, I've found the memory leak could up to 1400 mb then gc to 600mb(no player). u can use a plugin to track ur memory usage and send here. and u can test on Taco/Paper, it might not a burrito bug
I have already tested TacoSpigot, regular Spigot & PaperSpigot for 1.8.8. All of these forks produce results that yield less overall memory usage during a 24 hour period of running each of these forks.
Additionally, I have tried installing spark, however this reports a totally different memory usage compared to what the panel reports. I have spoken to people in the Pterodactyl Discord, and they are adamant that it's not related to Pterodactyl falsely reporting memory usage, which leads me to believe this is solely related to Burrito.
the plugin's mem report is totally differ than win taskmgr's. on win taskmgr it's always 2000mb after server starts.
the plugin's mem report is totally differ than win taskmgr's. on win taskmgr it's always 2000mb after server starts.
What's the best course of action I can take? I can't use TacoSpigot, Paper or regular Spigot since they are all heavily out of date, this is one of the only forks being maintained, but the memory usage is skyrocketing even with no plugins.
Use some bucks to add more ram... that's one of the reason why I think server panels are unsupported. my server(laptop) has 8 gb ram.
Use some bucks to add more ram... that's one of the reason why I think server panels are unsupported. my server(laptop) has 8 gb ram.
It's a dedicated server with 64 GB of RAM. The main problem server has 32 GB allocated, which is completely unreasonable.
how could a clear server get too much?!
how could a clear server get too much?!
The clear server had 4 GB of RAM allocated. I have also tried running the problem server on 12 GB of RAM to no avail - the memory usage spikes up suddenly. The problem server uses more than half the amount of memory using regular Spigot compared to BurritoSpigot, however of course regular Spigot has multiple vulnerabilities that this fork fixes.
could u just test on Windows?
could u just test on Windows?
Not really feasible since I don't have access to a Windows device at the moment. However, I don't see how testing on Windows would be any different than just testing outside of a containerised environment, so would you like me to try running the server without it being in a Docker container?
(The way Pterodactyl works is that each server is its own Docker container)
and test with zulu jdk 8
and test with zulu jdk 8
I'm not aware of what Zulu JDK 8 is, however I feel like to use a fork of Spigot in the most effective manner, I don't think it's fair to force/encourage people to use a specific version of JDK 8.
Please keep in mind I will not be able to conduct this test for a few hours since I am currently at work, when I'm back home I'll be more than happy to conduct this test.
I'll perform the test on whichever version of JDK 8 is available, whether it's Corretto, Temurin or something else.
Should take a spark heapdump to dump what's in the memory to see what's taking up all the ram. Doing a heapdump will save a file that's roughly the same size as how much memory is being using in the ram. After taking a heap dump, you can analyze the file using this tool. https://www.eclipse.org/mat/downloads.php
You generally want to take a heapdump after a few hours to a day of the server running so it's easier to findwhat's eating up the ram.
The amount of plugins don't determine how much memory the server uses since there can be a memory leak in one of the plugins you're using.
Should take a spark heapdump to dump what's in the memory to see what's taking up all the ram. Doing a heapdump will save a file that's roughly the same size as how much memory is being using in the ram. After taking a heap dump, you can analyze the file using this tool. https://www.eclipse.org/mat/downloads.php
You generally want to take a heapdump after a few hours to a day of the server running so it's easier to findwhat's eating up the ram.
The amount of plugins don't determine how much memory the server uses since there can be a memory leak in one of the plugins you're using.
As I've stated previously, I ran my tests on a server with no plugins, meaning that it's not possible for a plugin to be the cause of this strange rise in memory.
In addition, I was instructed to do a spark heapdump in the Pterodactyl Discord, after somebody analyzed it they concluded that it was not the fault of the panel, but rather with the fork of Spigot.
I do not know exactly where the issue lies, but at this point everything points to this Spigot fork rather than anything else.
As I've stated previously, I ran my tests on a server with no plugins, meaning that it's not possible for a plugin to be the cause of this strange rise in memory.
In addition, I was instructed to do a spark heapdump in the Pterodactyl Discord, after somebody analyzed it they concluded that it was not the fault of the panel, but rather with the fork of Spigot.
I do not know exactly where the issue lies, but at this point everything points to this Spigot fork rather than anything else.
oop, somehow missed the details about removing all the plugins.
Should upload the heapdump somewhere and link it here so the maintainer of this fork would be able to analyze it and potentially fix the problem. You could also use pandaspigot in the meanwhile.
Should upload the heapdump somewhere and link it here so the maintainer of this fork would be able to analyze it and potentially fix the problem. You could also use pandaspigot in the meanwhile.
I'm afraid I no longer have the heapdump on hand - I posted a Google Drive link in the Pterodactyl Discord but since then the file got removed.
Also, I'm unable to use PandaSpigot since it doesn't have a particular patch that is included in TacoSpigot that raises the packet size limit from 31 KB to 31 MB in 1.7+.
Describe the bug I have noticed a potential memory leak that's rooted within BurritoSpigot itself.
To Reproduce 1) Run a standard server using BurritoSpigot on a game server panel such as Pterodactyl. 2) Observe memory usage slowly rising with no plugins added at all, and no players joining or leaving.
Expected behavior I believe that there should be no reason for the memory usage to inexplicably rise.
Screenshots I am unable to provide screenshots.
What is your Java Version? This has occurred on Java 8 & Java 11.
What's your plugin list? None.
What is the error you see? (Please not an image) N/A
Additional context I have spoken to people within the Pterodactyl Discord, and all signs point towards this being an issue with BurritoSpigot as opposed to Pterodactyl falsely reporting memory usage.