You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When we moved the UKf deployment of this tooling to the new hardware in 2016, I set the memory for Java invocations in build.xml to 1GB but overrode that (again, for the UKf deployment only) with 1.5GB in prod.properties and preprod.properties which are the settings used by our production environment.
Note that in the UKf deployment, the value in build.xml is only used in development, not production. The idea is that you hit the limit in development, you know it's time to bump it before you hit the limit in production.
In early 2018, it looks like we needed to bump that build.xml value to 1.25GB but forgot to bump the values in the properties files.
Here we are in late 2019. I've just had to bump the value again to 1.5GB in build.xml, and this time I've increased the values in production to 2GB, so we're returning to the 0.5GB headroom we had in 2016.
This is all background, explaining how this works in the upstream UKf deployment. I don't know what values are used in the InCommon deployment, whether you're relying on the value in build.xml or whether you override the property in production. I also don't know how to compare the two deployments directly: the UKf deployment generates many output files from the same data.
It does seem reasonable, though, to review the production InCommon configuration in case we're getting close to a limit there as well, given the year-on-year increase in the size of both InCommon and eduGAIN metadata.
When we moved the UKf deployment of this tooling to the new hardware in 2016, I set the memory for Java invocations in
build.xml
to 1GB but overrode that (again, for the UKf deployment only) with 1.5GB inprod.properties
andpreprod.properties
which are the settings used by our production environment.Note that in the UKf deployment, the value in
build.xml
is only used in development, not production. The idea is that you hit the limit in development, you know it's time to bump it before you hit the limit in production.In early 2018, it looks like we needed to bump that
build.xml
value to 1.25GB but forgot to bump the values in the properties files.Here we are in late 2019. I've just had to bump the value again to 1.5GB in
build.xml
, and this time I've increased the values in production to 2GB, so we're returning to the 0.5GB headroom we had in 2016.This is all background, explaining how this works in the upstream UKf deployment. I don't know what values are used in the InCommon deployment, whether you're relying on the value in
build.xml
or whether you override the property in production. I also don't know how to compare the two deployments directly: the UKf deployment generates many output files from the same data.It does seem reasonable, though, to review the production InCommon configuration in case we're getting close to a limit there as well, given the year-on-year increase in the size of both InCommon and eduGAIN metadata.
Attn: @nroy @ij @dshafer
The text was updated successfully, but these errors were encountered: