Skip to content

Review heap allocation for production deployment #8

Open
iay opened this issue Aug 30, 2019 · 0 comments
Open

Review heap allocation for production deployment #8

iay opened this issue Aug 30, 2019 · 0 comments

Comments

@iay
Copy link
Contributor

@iay iay commented Aug 30, 2019

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.

Attn: @nroy @ij @dshafer

Sign in to join this conversation on GitHub.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.