![\"memory-diag1\"](\"http:\/\/smartfoxserver.com\/blog\/wp-content\/uploads\/2016\/06\/memory-diag1.png\")
<\/p>\nIn this article we’re going to address yet another oft-asked question regarding how SmartFoxServer uses memory and how to read the graph in the AdminTool’s Dashboard.<\/p>\n
When we open the Dashboard in SFS2X’s AdminTool we find, among other things, a diagram of the heap memory used to hold the application’s object instances.<\/p>\n
<\/p>\n
At a first glance the graph\u00a0shows two basic parameters, the amount of used memory (blue) and the allocated memory (cyan), but there’s more. At the top of the graph there’s a “Max” value of approximately 239 MBytes, which represents the top\u00a0limit that SmartFoxServer can\u00a0allocate, if needed. If our application required, for example, to allocate 300 MBytes of data it would incur in\u00a0an OutOfMemory error, \u00a0which is an unrecoverable exception and it would fail.<\/p>\n
In order to be able to solve this issue we need to add specific boot-time settings to make sure the JVM starts up with enough resources.<\/p>\n
Before we discuss it, let’s recap the three main parameters of JVM heap memory:<\/p>\n
When the\u00a0Java Virtual Machine boots up it\u00a0auto-determines a reasonable amount of memory to use based on the system’s configuration. On a Linux system with 2\u00a0GBytes of system RAM the JVM\u00a0will boot\u00a0with ~460MB of max memory, which is usually more than enough\u00a0for many SmartFoxServer use cases. On a 16GB server machine it will boot up with a max heap size of approximately\u00a03.5GBytes.<\/p>\n
Generally speaking SmartFoxServer 2X uses very little memory, it can even run with only 32 Mbytes of RAM and\u00a0it doesn’t need manual memory settings even when the traffic is in the thousands of CCU. However there can be situations in which more RAM is required especially when custom server side code is used, or very high traffic needs to be sustained.<\/p>\n
There are two main JVM parameters for setting the heap size at startup:<\/p>\n
-Xms<\/strong>: specifies the minimum heap size in MB or GB For example this combo: -Xms512M -Xmx2G<\/strong>, indicates that the JVM will start up with 512 MBytes of allocated heap and a maximum size of 2 GBytes.<\/p>\n These settings can be added via the SmartFoxServer’s AdminTool<\/strong> > Server Configurator<\/strong> > JVM Settings<\/strong>. You can read more about adding custom JVM settings in our documentation<\/a>.<\/p>\n On multiple occasions we have been contacted by developers that were monitoring their server and were worried that heap\u00a0memory seemed to\u00a0running out quickly, such as in this screenshot:<\/p>\n At a first glance it looks like the used heap is reaching the limit, but… if you just hold on\u00a0for a moment and look what happens a few minutes later…<\/p>\n The memory management inside the JVM is very smart but\u00a0works in an indeterministic way.\u00a0The used memory was growing fast in the first diagram because a number of unused objects were still held in the heap. In the 2nd screenshot we see the garbage collector (GC) cleaning up the used memory, while at the same time the allocated heap\u00a0is pushed up a bit, from ~95 MBytes to ~140 MBytes, which is still way below the limit of 466 MBytes, shown on top of the graph.<\/p>\n The moral of the story is that the JVM memory management\u00a0is difficult to predict for an external onlooker and usually there is no need to worry if the used and allocated memory seem to collide.<\/p>\n At this point one may be asking: if memory management is indeterministic and the behavior of the GC is unpredictable how do we know when we its time to fine tune the JVM’s memory?<\/p>\n Typically the red flag\u00a0is triggered by the allocated memory being pushed to the limit (allocated heap size == max heap size) and by frequent and small peaks and troughs of the used memory, indicating that the GC is very busy.<\/p>\n Here’s an example of a diagram that suggests manual intervention\u00a0is\u00a0in order:<\/p>\n This is definitely a case where improved heaps settings will help. If we run the same test with these JVM settings: -Xms512M -Xmx1G<\/p>\n we can see an entirely different picture, \u00a0with plenty of free heap in the allocated range and a much less frequent\u00a0GC activity in the same time range.<\/p>\n Before\u00a0we wrap this article up\u00a0we would also recommend not to get too carried away with\u00a0extra large amounts of memory as well. We have seen setups where the JVM was\u00a0assigned 12,16 or even more GBytes of RAM and unless there’s a very specific reason for this, we don’t recommend it.<\/p>\n Throwing king size amounts of heap memory at the JVM, with the purpose of minimizing the GC activity,\u00a0is counterproductive leading to\u00a0very long GC pauses that\u00a0could grind\u00a0the server to a halt\u00a0and make it\u00a0unresponsive for too long.<\/p>\n This means that all incoming traffic needs to be buffered and when the GC cycle ends there will be huge spikes of load resulting in more network spikes etc… Not the best behavior you would want from your server.<\/p>\n If you really need a very large heap size (> 8 GBytes) we recommend to also fine tune the garbage collector, maybe employing a concurrent\u00a0GC to avoid stopping the server’s active\u00a0threads.<\/p>\n Here are a few relevant articles if you’re interested to learn more about fine tuning the JVM<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" In this article we’re going to address yet another oft-asked question regarding how SmartFoxServer uses memory and how to read the graph in the AdminTool’s Dashboard.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[23],"tags":[70,69,68,40,34,7,71],"_links":{"self":[{"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/posts\/508"}],"collection":[{"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/comments?post=508"}],"version-history":[{"count":7,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/posts\/508\/revisions"}],"predecessor-version":[{"id":520,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/posts\/508\/revisions\/520"}],"wp:attachment":[{"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/media?parent=508"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/categories?post=508"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/tags?post=508"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n-Xmx<\/strong>: specifies the maximum heap size in MB or GB.<\/p>\n\u00bb\u00a0Common questions<\/h2>\n
![\"memory-diag2\"](\"http:\/\/smartfoxserver.com\/blog\/wp-content\/uploads\/2016\/06\/memory-diag2.png\")
<\/a><\/p>\n![\"memory-diag3\"](\"http:\/\/smartfoxserver.com\/blog\/wp-content\/uploads\/2016\/06\/memory-diag3.png\")
<\/a><\/p>\n\u00bb\u00a0When to intervene<\/h2>\n
![\"memory-diag4\"](\"http:\/\/smartfoxserver.com\/blog\/wp-content\/uploads\/2016\/06\/memory-diag4.png\")
<\/a>We forced the server to run with only ~40MB of RAM, this in turn provides a max size of 37 MBytes for the\u00a0heap. We\u00a0can see that the allocated memory is already maxed out and the\u00a0many\u00a0peaks and troughs indicate very frequent\u00a0garbage collections. In only 3 minutes of activity the GC was triggered\u00a0more than\u00a020 times.<\/p>\n![\"memory-diag5\"](\"http:\/\/smartfoxserver.com\/blog\/wp-content\/uploads\/2016\/06\/memory-diag5.png\")
<\/a><\/p>\n\u00bb\u00a0Too much memory can also be bad<\/h2>\n
\u00bb Learn more<\/h2>\n
\n