Excessive memory usage
Dr-WeiAL opened this issue · 38 comments
This is the memory footprint when Every Compat is not enabled
This is the memory footprint when Every Compat is enabled
latest.log
Why did this happen?Can this problem be fixed?
Reopening/bumping this, after testing on version 2.6.38 of the mod (1.20.1), the issue seems to be back, just adding the mod spikes my server's RAM usage from ~6GB to ~10GB and a long hang at the end of server loading! I don't even have that much mods... it makes it rather unusable. I did not have this problem before updating the mod so I assume it's a memleak/bug?
Edit: After going back to previous version, still high RAM usage, but without the mod it's much less... I don't understand lol.
this is NOT a bug!!
That's how the mod works. Infact that's how ANY mod works.
Add crazy amount of furniture mods + wood mods and EC will register an insane amount of blocks.
check your logs and it will have printed exactly how many
I do not have that much mods, that's the issue 😅 the server should not take that much RAM, but I think there's another issue...
You need to be aware of what content these mods are adding to the world. Like MehVahdJukaar said "Furniture mods + Wood mods" can increase the usage of RAM.
there is a reason why a modpack with 500+ requires at least 8GB to run smoothly and other modpacks with at least 4GB required because they have these mods that add contents to world. That's what he meant by "that's how mod works".
resource pack also required RAM, too. the higher the resolution of the resource pack, the higher the required RAM.
Try and isolate mods to see if any of them caused the high RAM usage. Once you solved the problem, Seeing that you are making a modpack, Take a look at Useful Information. it has useful info on how to make sure your server is running smoothly without any laggy.
Do not forget to use the internet to do your research so you can understand how to make a good modpack. there are tons of information and good advice.
also mod count doesnt mean anything. if you installed Chipped and biomes you'll go, that alone will be enough to bring any mid setup to its knees as block registered will be in the thousands
Here's my modlist, I made it pretty light on purpose, it should not take 10GB of RAM... but I noticed it only happens on the server, so that's super weird. EveryCompat still adds a ton of RAM usage though, but I'm starting to think it's also something else... I'll make some tests and send the server logs if I can't find anything else.
modge.txt
Edit: It was literally WorldEdit adding a whole 5GB OF RAM CONSUMPTION to the server o_o, I thought it was EveryCompat because after removing it, it went from 10GB to 6GB... I think both of them work really not good together.
Here's the latest.log after reproducing on client if you want to see it, after loading a world:
https://mclo.gs/FK8Fhka (With WE+EveryCompat: 10GB RAM)
Without EveryCompat: 7GB RAM
Without WE/EveryCompat: 4GB RAM
It's just worldedit having an issue with registering blocks or something
ok so i remember about this. Worldedit is absurdy underoptimized and takes an absurd amount of ram which is proportional to block registered (technically blockstates). Theres no excuse for something like that imo, 3gb just fro vanilla is crazy. In other world world edit heavily amplifies the amount of ram that EC (and any other mod) uses. Infact its world edit thats using this ram not EC
Ah, I remember the cause is World Edit from another issue with a similar content. now you know which mod to not use. just remove WE and you should find an alternative mod to WE.
There is nothing there to fix. If you install a million mods that add wood types and a million mods that add furniture's Evey comoat will do its job and registere a block of those furnitures in all those wood types. This can easily explode, I've see. Some extreme cases with a person that had 800 mods and with that many EC literally doubled the ram the game used,l, registering over 50k blocks. You can see how many blocks ec registered in the logs
It looks like there are 5910 blocks?
There are 10*16 blocks on a page, 37 pages in total, about the same number as in the log, okay
So this problem is not a bug, but a problem with Minecraft itself?
Game objects need memory to exist. That's just how computer works. And the game isn't that optimized to handle similar blocks like that so the resources it takes are the same for every block, even increasing if they have more blockstates. Problem is that you have way too many furniture or wooden mods. Depends on what you want to do here, choice is up to you. You have to choose if you would rather have more blocks but with incomplete wood sets or fewer but with complete wood sets
Is it possible to implement this without adding actual blocks? Sort of like how Tinker's Construct works
Yeah in theory it's possible. You would just need to make every single block a tile entity instead. This would be a lot more work tho as a custom implementation for each and every modded block would be needed to let them have a tile and a custom baked model to have said tile switch texture depending on wood type. Not to mention all the discrepancy that would come from the difference between the original blocks and this very different implementation.
On another note chipped compat is coming soon so if you got that installed expect the registered blocks to double
Any chance we could get a config to disable certain generated features? I love all the extra door variants and Decorative Blocks support but I would like to disable all the furniture from Macaw's Furniture and MrCrayfish's Furniture Mod.
Configs cannot alter what gets registered or not otherwise two clients with the same mod will not be able to connect to the same server if configs are different. I'll state once again that the choice is left to the player. Either disable some of those millions furniture mods or play with incomplete wood sets
Does that mean setting a item to false in "everycomp-wood_type.toml" wouldn't help with the ram issue?
is the configs not altering what gets registered a decision by you or by forge? as I feel a mod that can bloat so much that it can double loading times and ram usage might be a bit of an exception to that rule.
Would it be possible to break the mod into several smaller mods to help manage the ram?
No I really don't see the point. If one likes every compat means that they appreciate having quality over quantity meaning afew well integrated wood sets are better than a bunch that just have vanilla stuff. If I were to break it up first of all I wouldn't know how to split it (1 add-on for each mod??) And second it defeats the purpose of the mod as it would imply people having incomplete wood sets. If you want less ram usage uninstall some furniture mods, you don't need a million chairs and such
The problem is I don't have a million Chairs and such. yet I can still spike up to 6 gigs of ram usage when adding your mod to a light pack of less than 100 mods. You have compatibility with so many different mods(which is a great thing and this is a fantastic mod!) that its starting to become harder to use in mod packs where it really shines. Id assume you'd break it up into smaller parts based on ram usage, for example bundle all of macaws compats, chipped would be its own, and then the rest could be part of the main mod. This is a quality mod, however its quality really shines when it doesn't bring minecraft to a halt. I personally think disabling based on config is a great way to go because its unlikely the server and client would have a different config to begin with. But as the chipped module has shown the more compatibility you add the harder the mod will become to use in its element.
It really depends on what mods you have. You could have a few furniture mods but maybe it is huge ones like chipped or maybe you just have many mods that add wood types. If you check your log it will say how many blocks the mod registered and wat mod is the biggest offender. Config is a no go for me. Dynamic registration is frowned upon by forge and is only really possible here as it depends on loaded mods so it's not truly dynamic. If you do have that then there will be a million reports of people complaining about not being able to connect to servers even with same mods. That's not user friendly and just confusing, imo should almost never be done. My point is that you should really install this mod if you prefer quality over quantity. If you would rather have some incomplete wood sets then this isn't for you to begi with
I understand what you mean. though I would not call a mod that makes the game crawl by doubling the amount of registered blocks. "quality over quantity" its more the reverse of quantity over quality. I beg you to at consider making it a "series" of mods with compatibility spread out between them to help manage the ram. as you've said in your own words it can literally double the ram used. I'm sorry if I've caused any trouble. It's an awesome mod and I just wish it was more playable.
It does that if you already have a bunch of other mods on. When I first made this I made it for myself and I would only ever use 4 modules or so that the mod adds. All the others were asked by people or added by some contributors so they kept piling up. Once again the choice remains to the user. Do you prefer a couple complete wood sets or many non complete ones? The mod offers no in between, if you want to have both you'll need more ram. I've seen people have the mod register up to 24k blocks in some crazy circumstances or could be as few as you want. So just to be clear what mods would you keep and what would you cut meaning which of them would you prefer to not have modded wodtypes of? I mean I'm not a fan of stuff with low integration so for me if I had to say install a chairs mod that doesn't have a biome mod wood types I won't install one of the two.
Plus the mod was also meant to replace the current parading of having a single mod for compat per each mod pair, say between quark wood types and twigs tables or something and was supposed to replace and make all those obsolete with a single universal mod (hence the name)
Configs cannot alter what gets registered or not otherwise two clients with the same mod will not be able to connect to the same server if configs are different. I'll state once again that the choice is left to the player. Either disable some of those millions furniture mods or play with incomplete wood sets
Is that not what the purpose of a "common" config is? I thought it was assumed that the config will be the same between the server and the client.
Nope. Common just means it's supposed to contain stuff that could be needed both on server and on clients. There's no syncing whatsoever done on those. Server configs are. Tho syncing common confugs can be done so when a client joins a server those are shared and say client displayed informaitons on tooltips Ans whatnot is consistent. I do It in many of my mods. This is irrelevanto however. Registration happens on boot. There's no server there and even if there was which would it be? From the millions one you could connect and that would have different config that you do
No I really don't see the point. If one likes every compat means that they appreciate having quality over quantity meaning afew well integrated wood sets are better than a bunch that just have vanilla stuff.
It's your mod, and you are well within your rights to do as you like with it, but I have to say this strikes me as odd reasoning. Having 20+ pages of different colored planes when I just want some blue furniture is... not what I would typically view as a quality over quantity approach. If I were making a modpack just for myself it would be workable, because I can afford to just dump massive amounts of RAM at Minecraft, but much of my friend group isn't as fortunate, so I sadly have to pass it over. While having one massive mod to cover every combination of wooden block and type of wood is is a useful approach, I don't think it would lose its value if it was divided into parts for specific mods (or with the option to blacklist certain mods). To me the (hypothetical, anyway) utility of the mod is the scope of the compatibility, not the range of installation. I would install dozens of wood compatibility mods if it meant being able to curate the modpack down to a relatively efficient core.
Guys,
There is another way to fix the RAM issue. you just need to clone the repository of Every Compat for the Minecraft version and go to class WoodGood.java (1.18.2) or EveryCompatForge.java, EveryCompatFabric.java, EveryCompat.java depending on Loaders so you can comment out these supported mods that you don't want to be supported by EveryCompat mod. From here, you can compile the jar. Idk if MehVahdJukaar is fine with this solution.
note: this is for these who knows the basics of coding.
Guess we could add a manual config override. A sort of edit at your own risk kind of deal that would turn off modules. Wonder what would be a nice name and location that screams "don't edit me if you don't know what you are doing" as you know that thing would have to be exactly the same from server to client
Guess we could add a manual config override. A sort of edit at your own risk kind of deal that would turn off modules. Wonder what would be a nice name and location that screams "don't edit me if you don't know what you are doing" as you know that thing would have to be exactly the same from server to client
Perhaps you could store the file under a different format than usual? E.g. modernfix has a mostly useless common .toml config, and its actual settings are stored away behind a .properties file with comments saying that you should be using the in-game mod GUI instead. Alternatively, having a secondary config with an obscure name that you wouldn't be looking for unless you read the documentation might help.
that's why I added "note:" at the end. Those who know the basics of coding would know that the client and server gotta have the same setup or version. I hope that message also say "stay away from editing if you don't know how to code". tbh, I thought EC already has a manual config override. but nope.
it needs to be addressed.