Increase Xmx and Xms to 3072M for All 64bit Releases (2.5.22294) #9654
Comments
|
After I made my opponent increase the I would label this problem as "Major" if it would happen to a game which I believe is popular (but "270BC Wars" is certainly not). |
|
I wonder if you removed the option if you would have better performance. I'm curious if you did so, how much memory would be allocated. Bottom line, we should favor using JVM defaults for memory allocation rather than overriding those defaults. There are some subtle pitfalls with overriding memory defaults (not to mention potential pauses from very long Garbage Collection (GC) cycles). |
|
I don't have a problem myself: I keep it at 4GB and everything seems working fine (the process often actually stays well under 4GB). It is a long time I've not played it while having it at 2GB, but I remember having some issues like what described at this issue. This issue comes up just because something like this sometimes happens to the user I'm playing with, and it gets fixed by making him/her increase the setting to 4GB (but it would be game-breaking if all users in the game have no idea about what to do). I think I've never tried having no settings. Are you sure the program doesn't have a default setting which is used (just like in the case you have that value) if you have nothing specified in "vmoptions"? Are you sure that the proposed 3GB would be problematic for systems having 4GB? I guessed it would be fine, since that leaves 1GB out. To work fine with 4GB systems is the reason why I proposed 3GB instead of 4GB. |
Mostly, the JVM does a computation to determine min, starting, and max memory if not specified. Specifying those values overrides any defaults chosen by the JVM. Generally it is advised to let the JVM compute these values.
It might not be, it could. It certainly would be a problem for systems with less than 3GB available or even total memory (eg: 2GB systems). |
|
Here it is yet an other example (This was until a few minutes ago, and I was privately hosting in the lobby.):
|
|
It's almost always better to use JVM defaults entirely. This takes into account the system, the current load, and it's requirements. For example, the min size of having 3GB means an 8GB system will run out of memory as soon as you connect to two games (3GB for the lobby, which consumes the exact same memory as the app, then 3GB for that first game, then not enough memory to connect to a second). If instead we got rid of vmoptions entirely the main app would probably consume around 100MB or so, then the game apps would grow in their memory usage to some default max of the system. In other words, the system should already be increasing the amount of memory needed when it needs it. It is perhaps not precisely because we are specifying a max memory. Thus by specifying a max memory we are actually reducing the effective max available (we are capping it), and by specifying a min memory we are potentially using far more memory than would be needed to run the lobby window. It's also not conclusive to just make that update and see if things worked. Closing out additional windows can free up memory, restarting the app could resolve memory leaks, or it could be other processes reduce their memory consumption freeing up more memory for the OS. The general rule of thumb is to eliminate any non-defaults for memory usage unless truly needed otherwise. It could be that most of these problems are avoided if we entirely remove the min/max setting and allow the JVM to use its algorithm to do that (which has been tuned and developed by far smarter people and far more systems than we have experience) |
|
Said perhaps more simply, by default, when not specified, xms is usually around 100MB and xmx is 2/3 the total available memory. IF we then removed the xmx and xms specification, we would save on memory for the main game screens that require almost no memory, and you would get a much bigger max memory available as well (if and when it were needed, the JVM dynamically requests more memory from the OS when it is needed). |
I certainly believe it is good being able to set the items presented in that file without having to use any commands, so I like that file not to be removed. However, instead of removing the file from the package, the default entries for the wanted items may be left blank and that meaning using JVM defaults (so power users still have the file if they want to add values to it). Meaning that the file, once opened with a text editor, may look like this (if this is actually better for the problem at hand): I may try to remove the file and see how it goes for me. I confirm that the problem with the most recently mentioned user was that, upon using the battle-calculator, the game would crash for him/her and this didn't happen any longer, for the remaining hours we played, once he/she doubled the default memory values given in the |
|
How about having the program first looking for an (optional) |
|
I've recently increased my "TripleA.vmoptions" values to as much as because of hitting the 4G RAM cap during a "270BC Wars" game I was hosting sometime after round 10. Everything seems fine now. Here it is a lobby "report" that I suspect is due to the standard 2G RAM cap.
|
|
Further testing gives me some strong evidence that there must be some serious memory leaks on reloading. I mean that, if you keep closing the game (but not the host), loading the save and relaunching it, the memory taken by the process keeps going up more and more every time you do it. Thus, if you keep reloading a lot on the same host, eventually you'll hit even 4GB. Closing the host completely (and reloading after rehosting) fixes the problem, bringing the memory of the process back within 1GB. |
|
Update: Xmx & Xms are no longer specified. This should have the effect of increasing max memory where it is available. There is some information at the following links for what the defaults are: Please do re-open this issue if any questions or follow-up desired (or cut a new issue), otherwise will mark this as closed for now |
I request changing the first two lines of the
TripleA.vmoptionsfile to:This change should be applied at least to the "windows-64bit" release and should not be applied to the "windows-32bit" one. I don't know if it should be applied to other releases.
The reason for the change is that the current default appears to be too low to properly support the "270BC Wars" game, giving errors when it is not enough, and may even cause the game to freeze indefinitely.
I think this change should cause virtually no problems, as I surmise that virtually everyone who is using a 64 bit system is likely to have 4G or more of memory (and, in any case, the 32 bit version is still available for download, for anyone having less than 4G of RAM).
I had several occurrences which seemed to show the default
Xmxbeing too low. Here are all the relevant chat-log excerpts from the last of these cases, which happened yesterday (meaning a few hours ago, for me).My host:
Thence the lobby:
Thence my host again:
The text was updated successfully, but these errors were encountered: