Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1462350

Summary: unqualified search on hostgroup page results in large memory spike and potential OOM
Product: Red Hat Satellite Reporter: Justin Sherrill <jsherril>
Component: Host GroupAssignee: Justin Sherrill <jsherril>
Status: CLOSED ERRATA QA Contact: jcallaha
Severity: high Docs Contact:
Priority: high    
Version: 6.2.10CC: andrew.schofield, bbuckingham, bkearney, cduryee, inecas, jcallaha, ktordeur, tbrisker, zhunting
Target Milestone: UnspecifiedKeywords: FieldEngineering, PrioBumpField, Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: foreman-1.11.0.81-1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1463802 (view as bug list) Environment:
Last Closed: 2017-08-10 17:02:29 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:
Attachments:
Description Flags
Patch
none
verification screenshot none

Description Justin Sherrill 2017-06-16 19:50:56 UTC 
Description of problem:

When you have a large number of host groups, and a large number of associated puppet classes, searching for hostgroups via the UI or api can cause a huge spike of memory if the search is unqualified (i.e. does not include 'field=value', but instead is just 'value').

Version-Release number of selected component (if applicable):
6.2.9/6.3.0

How reproducible:
Always (with user data)

Steps to Reproduce:
1.  On a system with lots of hostgroups and puppet class associations
2.  Navigate to config > hostgroups
3.  search for "FOO"  where FOO is the name of a hostgroup

Actual results:
Passenger memory balloons by many gigs, OOM killer may kick in

Expected results:
No major memory usage increase


Additional info:
Comment 1 Justin Sherrill 2017-06-16 19:53:00 UTC 
Sample user data:

> Hostgroup.count
=> 248

> Puppetclass.count
=> 234

> HostgroupClass.count
=> 2248
Comment 3 Justin Sherrill 2017-06-16 19:58:00 UTC 
Created redmine issue http://projects.theforeman.org/issues/20038 from this bug
Comment 4 Justin Sherrill 2017-06-16 20:09:34 UTC 
Created attachment 1288458 [details]
Patch
Comment 5 Satellite Program 2017-06-16 20:11:40 UTC 
Upstream bug assigned to jsherril
Comment 6 Satellite Program 2017-06-16 20:11:43 UTC 
Upstream bug assigned to jsherril
Comment 7 Satellite Program 2017-06-18 12:12:50 UTC 
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/20038 has been resolved.
Comment 10 jcallaha 2017-07-27 19:56:32 UTC 
Verified in Satellite 6.2.11 Snap 2

I used the steps provided in the original description.

Hostgroups: 251
Puppet Classes per HG: 635

When performing the unqualified searches "clone", "clone10", "clone109"; no search took longer than 1.5s for the page to return. Average load times were around 600ms. See attached screenshot for search and browser timeline. Additionally, monitoring the memory usage in the machine showed no significant memory spikes.
Comment 11 jcallaha 2017-07-27 19:57:01 UTC 
Created attachment 1305640 [details]
verification screenshot
Comment 13 errata-xmlrpc 2017-08-10 17:02:29 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2466