Bug 817890
Summary: | jbossas-7 configure hook is expensive | ||
---|---|---|---|
Product: | OKD | Reporter: | Rob Millner <rmillner> |
Component: | Containers | Assignee: | Dan Mace <dmace> |
Status: | CLOSED NOTABUG | QA Contact: | libra bugs <libra-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 2.x | CC: | dmace, mfisher, mmcgrath |
Target Milestone: | --- | Keywords: | FutureFeature, Triaged |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-10-10 18:30:58 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Rob Millner
2012-05-01 17:41:52 UTC
This is almost entirely the JBoss start time. The configure hook waits for JBoss HTTP to become available and this takes the vast majority of the time in the hook. There isn't much we can do about this. The cpu limitations are the critical factor - if we remove the cpu limit, JBoss starts significantly faster. Passing to Mike for followup on cgroups cpu quota. The numbers may need to be adjusted or it may just cost too much. A new benchmark run has started. It should run until tomorrow and then some analysis is required to process the results. https://ci.dev.openshift.redhat.com/jenkins/job/libra_benchmark/25/ Also, the other Jenkins jobs and build scripts have changed significantly since this task was last run so it may require fixing and re-run. The previous job had failed. Bug has been fixed and a new benchmark run started: https://ci.dev.openshift.redhat.com/jenkins/job/libra_benchmark/26/ Came across another issue. Our external DNS provider has become unstable enough that its proving impossible to get a good benchmark over the 8 hours it takes to run. I'll see what can be done to work around this issue but suspect its not going to be done in this sprint. At present /etc/resolv.conf references localhost as a valid resolver, it shouldn't that should be removed before we can test if there's additional external issues. Bug Triage - We believe this to be mostly fixed now. |