Bug 1031967
| Summary: | Consider re-doing the ResourceConfiguration checking | ||
|---|---|---|---|
| Product: | [Other] RHQ Project | Reporter: | Heiko W. Rupp <hrupp> |
| Component: | Performance, Plugin Container | Assignee: | Heiko W. Rupp <hrupp> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike Foley <mfoley> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.9 | CC: | hrupp |
| Target Milestone: | --- | ||
| Target Release: | RHQ 4.10 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-04-23 12:29:59 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1069642 | ||
Actually we should directly write those resource.resourceConfig items to disk when we receive them from the server and null out that field to reduce memory consumption and not wait until the checker runs. master ea1f3b8 Bulk closing of 4.10 issues. If an issue is not solved for you, please open a new BZ (or clone the existing one) with a version designator of 4.10. |
ConfigurationCheckExecutor has the following code Configuration original = resource.getResourceConfiguration(); if (!liveConfiguration.equals(original)) { log.info("New configuration version detected on resource: " + resource); this.configurationServerService.persistUpdatedResourceConfiguration( resource.getId(), liveConfiguration); resource.setResourceConfiguration(liveConfiguration); (which runs in a tight loop for a long time, thus using a lot of CPU and blocking other work, but that is a different story; 2013-11-11 14:43:49,292 INFO [ConfigurationManager.threadpool-1] (rhq.core.pc.configuration.ConfigurationCheckExecutor)- Configuration update check completed in 544077ms). This assumes that we keep all resource configurations in memory. Such a configuration can use several kilobytes (for my current, already slightly tuned, heap, 7000 Configuration objects with ~64k PropertySimple take 12MB, with ~2100 resources, that is on average 5KB/resource) and with thousands of resources in memory that support configuration, this easily adds up to several Megabytes of heap. As the configuration checking and also updating only happens infrequently, we could passivate those configurations to disk and read them back on demand, thus freeing a lot of heap.