Hide Forgot
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:
Sample user data: > Hostgroup.count => 248 > Puppetclass.count => 234 > HostgroupClass.count => 2248
Created redmine issue http://projects.theforeman.org/issues/20038 from this bug
Created attachment 1288458 [details] Patch
Upstream bug assigned to jsherril
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/20038 has been resolved.
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.
Created attachment 1305640 [details] verification screenshot
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