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

Include a default config overlay for docker-best-practice values #105

Closed
ebullient opened this Issue Jan 16, 2017 · 3 comments

Comments

Projects
None yet
3 participants
@ebullient
Member

ebullient commented Jan 16, 2017

a) turn off file polling (switch to mbean)
b) set coreThreads to a reasonable value (5) so the executor service isn't going off of potentially bad virtualized values.
c) turn off deferred application start

Something like the following in configDropins/defaults:

    <!-- turn off polling -->
    <config updateTrigger="mbean" />
    <applicationMonitor dropinsEnabled="false" updateTrigger="mbean"/>

    <!-- This is required to prevent the web apps from being lazily loaded -->
    <webContainer deferServletLoad="false"/>
    <!-- The JVM can get confused about available CPU in virtualized envs -->
    <executor coreThreads="5"/>
@arthurdm

This comment has been minimized.

Show comment
Hide comment
@arthurdm

arthurdm May 29, 2018

Member

Some of our docs from Docker Hub demonstrate using the dropins folder, so it would be weird if that didn't work without an additional server.xml to override that default.

I realize that this issue was opened over a year ago, so since then there has been work in Liberty 18001 for optimizing the executor cores in cloud environments.

Do you still feels there's particular config for a docker container environment that wouldn't also be a best practice for outside a docker environment?

Member

arthurdm commented May 29, 2018

Some of our docs from Docker Hub demonstrate using the dropins folder, so it would be weird if that didn't work without an additional server.xml to override that default.

I realize that this issue was opened over a year ago, so since then there has been work in Liberty 18001 for optimizing the executor cores in cloud environments.

Do you still feels there's particular config for a docker container environment that wouldn't also be a best practice for outside a docker environment?

@gjdeval

This comment has been minimized.

Show comment
Hide comment
@gjdeval

gjdeval May 29, 2018

Changes made in Liberty 18001 to the Liberty DefaultExecutor initialization default behavior (when coreThreads is not set) take account of Docker container cpu allocation, in addition to other factors. So afaik Liberty default threadpool sizing should work 'properly' in Docker from 18001 on, so the coreThreads setting should not be required. Liberty will start the pool at twice the number of 'virtual cpus' configured in Docker, analogous to the starting point of twice the number of hardware threads in non-Docker environments.
If/when we discover Docker configs that don't seem to be starting the threadpool by default at a reasonable size, I'd love to know the particulars so we can adapt to properly handle that situation as well.

gjdeval commented May 29, 2018

Changes made in Liberty 18001 to the Liberty DefaultExecutor initialization default behavior (when coreThreads is not set) take account of Docker container cpu allocation, in addition to other factors. So afaik Liberty default threadpool sizing should work 'properly' in Docker from 18001 on, so the coreThreads setting should not be required. Liberty will start the pool at twice the number of 'virtual cpus' configured in Docker, analogous to the starting point of twice the number of hardware threads in non-Docker environments.
If/when we discover Docker configs that don't seem to be starting the threadpool by default at a reasonable size, I'd love to know the particulars so we can adapt to properly handle that situation as well.

@arthurdm

This comment has been minimized.

Show comment
Hide comment
@arthurdm

arthurdm May 30, 2018

Member

Thanks for the info @gjdeval

Closing this issue, given the reasons from the last 2 comments.

Member

arthurdm commented May 30, 2018

Thanks for the info @gjdeval

Closing this issue, given the reasons from the last 2 comments.

@arthurdm arthurdm closed this May 30, 2018

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