Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Java VM limits should match (per Atlassian recommendation) #50

Open
rwarren opened this issue Jun 20, 2018 · 7 comments
Open

Java VM limits should match (per Atlassian recommendation) #50

rwarren opened this issue Jun 20, 2018 · 7 comments

Comments

@rwarren
Copy link
Contributor

rwarren commented Jun 20, 2018

The current blacklabelops docker-compose.yaml Java VM settings are as follows:

    environment:
      - 'CATALINA_OPTS= -Xms256m -Xmx1g'

The Atlassian recommendations on this page state:

In the general case, both Jira & Confluence users will benefit from setting the minimum and maximum values identical

So it seems that this should be changed to:

    environment:
      - 'CATALINA_OPTS= -Xms1g -Xmx1g'

Same applies to the JIRA config... although (for JIRA) I do wonder at the blacklabelops default Xmx value of 1 GB, when the general guidance from Atlassian themselves is:

Granting Jira applications too much memory can impact performance negatively, so it is best to start with 768 MB, and make modest increases as necessary

Bumping to 1 GB seems reasonable to me, but... Java isn't my thing (thankfully) and I'm wary of direct guidance saying not to allocate too much!

@ckotte
Copy link

ckotte commented Aug 10, 2018

The docker-compose.yml needs to be adjusted. You need to specify CATALINA_PARAMETER1, CATALINA_PARAMETER_VALUE1, and so on to set the CATALINA_OPTS.

For Jira it's JVM_MINIMUM_MEMORY and JVM_MAXIMUM_MEMORY.

The default configuration if you don't specify additional environment variables:

Product Java VM Settings
Confluence -Xmx1024m -Xms1024m
Jira -Xms384m -Xmx768m

@blacklabelops
Copy link
Member

Jira Image is configured differently. This changed recently: https://github.com/blacklabelops/jira#a-word-about-memory-usage

@rwarren
Copy link
Contributor Author

rwarren commented Aug 10, 2018

I'm confused.

  1. Are the JVM_xxx_MEMORY settings a replacement for CATALINA_OPTS or in addition to CATALINA_OPTS?
  2. Does this change only apply for recent JIRA versions, or is it an issue with the container?

Also, per the original reason for this issue, their docs still say to set the min and max the same.

To cover off possible versioning issues, is this how the environment section should look like for these vars in the docker compose file?

    environment:
      JIRA_DATABASE_URL: <snip>
      JIRA_DB_PASSWORD: <snip>
      CATALINA_OPTS: -Xms1024m -Xmx1024m
      JVM_MINIMUM_MEMORY: 1024m
      JVM_MAXIMUM_MEMORY: 1024m

@ckotte
Copy link

ckotte commented Aug 10, 2018

Looks like Jira uses the JAVA_OPTS environment variable. You can check this in /opt/jira/bin/setenv.sh in the Docker container.

You need to specify:

environment:
      JIRA_DATABASE_URL: <snip>
      JIRA_DB_PASSWORD: <snip>
      SETENV_JVM_MINIMUM_MEMORY: 1024m
      SETENV_JVM_MAXIMUM_MEMORY: 1024m

The docker-entrypoint script uses the environment variables you specify in the Docker compose file to configure the variables in setenv.sh for Confluence/Jira.

@blacklabelops
Copy link
Member

According to Atlassian documentation they changed the memory configuration also for Confluence:
https://confluence.atlassian.com/confkb/how-to-fix-out-of-memory-errors-by-increasing-available-memory-154071.html

Can somebody check if either CATALINA_OPTS or JVM_MINIMUM_MEMORY, JVM_MAXIMUM_MEMORY still works? Maybe we will need an issue here.

@ckotte
Copy link

ckotte commented Aug 10, 2018

The Confluence image is fine. -Xmx1024m, -Xms1024m, and -XX:+UseG1GC are still configured via CATALINA_OPTS in /opt/atlassian/confluence/bin/setenv.sh. -XX:MaxPermSize is not set at all.

@blacklabelops
Copy link
Member

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants