Fantom uses a default maximum heap memory allocation setting of 512MB. If you have a large application you may need to increase this max value by changing the value specified in etc/sys/config.props (the last line java.options=-Xmx512M).
If there is no max heap flag provided as an option, the default behavior depends on the amount of system RAM and whether the platform is a 32 or 64 bit architecture. The rule of thumb to use is that Java will use less than 1/4th of the physical memory as the maximum heap size.
Does anyone see any major issues for Fantom if we leverage the default behavior rather that specifying a default maximum heap option of 512MB?
Best regards, Ross
SlimerDudeSat 11 Jan 2020
Hi Ross,
For the benefit of others on the forum (as not everyone here is involved with SkySpark) I thought I'd take this opportunity to introduce you...
Ross is a new member of SkyFoundry, the custodians of Fantom, and works closely with Brian and Andy Frank. So similar to Matthew Giannini, any views or ideas expressed by Ross can be taken as an official Fantom stance.
Ross, to answer your question, I see no major issues with reverting to Java's default behaviour - but it will mean more maintenance work for me when setting up new Fantom based web servers.
I have a lot of smaller web servers for hosting various Fantom websites and typically these machines have between 512MB to 1GB of RAM. So the current default setting means the servers will always start with good sized chunk of RAM, which is great given the Fantom process is the main process running on the machine.
The default now means Java will max out at 128MB to 256MB (1/4 of the total) so I'll need to update the various Fantom install scripts to set a more sensible default. (And working with .props files with bash cmds is no easy task!)
It's also an extra step to consider / be taken when manually setting up servers.
So while I'm not against removing the current default, I am interested in why you feel the need to remove it?
Cheers,
Steve.
Phillip BirchSat 11 Jan 2020
From a SkySpark VAR perspective, i'm fairly neutral. Unlike Steve, I usually spin up Fantom in larger servers where I would be touching etc/sys/config.props to set the maximum memory heap based on the system anyway. That being said, if the group does decide to remove the limit that would be fine as well!
Thanks, Phil
rossFri 24 Jan 2020
Thanks for the introduction Steve. Apologies I missed the email that there had been a response. The goal is to have a more sensible default. I think there obviously is a need for supporting smaller systems, which makes it difficult to raise the default value, but by setting a hardcoded value it seems to limit your ability to change the behavior any other way than through the config.props file.
For example, I have been testing using the JAVA_TOOL_OPTIONS environment variable to specify my Xmx option. The beauty of this from the SkySpark perspective is not needing to remember to update config.props after each upgrade. That would be used across all Fantom/Java applications on the system so that must be considered, but I would think other Fantom applications would benefit from that configurability as well.
Best regards, Ross
SlimerDudeSat 16 May 2020
Hi Ross,
Just to say that on further reflection I think removing the default -Xmx setting is good idea.
If anyone has any hard memory requirements for Java then they should really be explicitly setting the options themselves.
ross Fri 10 Jan 2020
Hello,
Fantom uses a default maximum heap memory allocation setting of 512MB. If you have a large application you may need to increase this max value by changing the value specified in etc/sys/config.props (the last line
java.options=-Xmx512M
).If there is no max heap flag provided as an option, the default behavior depends on the amount of system RAM and whether the platform is a 32 or 64 bit architecture. The rule of thumb to use is that Java will use less than 1/4th of the physical memory as the maximum heap size.
Does anyone see any major issues for Fantom if we leverage the default behavior rather that specifying a default maximum heap option of 512MB?
Best regards, Ross
SlimerDude Sat 11 Jan 2020
Hi Ross,
For the benefit of others on the forum (as not everyone here is involved with SkySpark) I thought I'd take this opportunity to introduce you...
Ross
is a new member of SkyFoundry, the custodians of Fantom, and works closely with Brian and Andy Frank. So similar to Matthew Giannini, any views or ideas expressed by Ross can be taken as an official Fantom stance.Ross, to answer your question, I see no major issues with reverting to Java's default behaviour - but it will mean more maintenance work for me when setting up new Fantom based web servers.
I have a lot of smaller web servers for hosting various Fantom websites and typically these machines have between 512MB to 1GB of RAM. So the current default setting means the servers will always start with good sized chunk of RAM, which is great given the Fantom process is the main process running on the machine.
The default now means Java will max out at 128MB to 256MB (1/4 of the total) so I'll need to update the various Fantom install scripts to set a more sensible default. (And working with
.props
files with bash cmds is no easy task!)It's also an extra step to consider / be taken when manually setting up servers.
So while I'm not against removing the current default, I am interested in why you feel the need to remove it?
Cheers,
Steve.
Phillip Birch Sat 11 Jan 2020
From a SkySpark VAR perspective, i'm fairly neutral. Unlike Steve, I usually spin up Fantom in larger servers where I would be touching
etc/sys/config.props
to set the maximum memory heap based on the system anyway. That being said, if the group does decide to remove the limit that would be fine as well!Thanks, Phil
ross Fri 24 Jan 2020
Thanks for the introduction Steve. Apologies I missed the email that there had been a response. The goal is to have a more sensible default. I think there obviously is a need for supporting smaller systems, which makes it difficult to raise the default value, but by setting a hardcoded value it seems to limit your ability to change the behavior any other way than through the config.props file.
For example, I have been testing using the JAVA_TOOL_OPTIONS environment variable to specify my Xmx option. The beauty of this from the SkySpark perspective is not needing to remember to update config.props after each upgrade. That would be used across all Fantom/Java applications on the system so that must be considered, but I would think other Fantom applications would benefit from that configurability as well.
Best regards, Ross
SlimerDude Sat 16 May 2020
Hi Ross,
Just to say that on further reflection I think removing the default
-Xmx
setting is good idea.If anyone has any hard memory requirements for Java then they should really be explicitly setting the options themselves.
brian Mon 18 May 2020
Ticket promoted to #2781 and assigned to brian
brian Mon 18 May 2020
Ticket resolved in 1.0.75
I will make this change for upcoming build