Bug 758864

Summary: Explanation for aviary_query_server memory usage
Product: Red Hat Enterprise MRG Reporter: Pete MacKinnon <pmackinn>
Component: Release_NotesAssignee: Tomas Capek <tcapek>
Status: CLOSED CURRENTRELEASE QA Contact: ecs-bugs
Severity: high Docs Contact:
Priority: high    
Version: DevelopmentCC: matt, tmckay
Target Milestone: 2.2Keywords: Documentation
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-20 01:01:27 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Pete MacKinnon 2011-11-30 20:46:20 UTC
The Axis2/C engine retains a stream buffer for responses. It doesn't reallocate based on the size of each new response but instead just checks instead to see if the old one will fit the new data to be written. If not, then a new buffer is allocated and the old one freed. Thus, over time, the buffer will remain at a high water mark of the last largest response size. In the case of the aviary_query_server and depending on the operation invoked, the RES of the process will grow because of the heap still in use. For example, a request for 1 job status after a request for 500 job details will not grow the RES of the process (other non-RPC memory allocations notwithstanding). Customers can simply restart the aviary_query_server daemon if they are concerned about the apparent RES size. The aviary_query_server will reconstruct its internal job collections and the Axis2/C response buffer will be reset.