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 1436918

Summary: Ruby, passenger-foreman memory is growing huge at scale.
Product: Red Hat Satellite Reporter: Pradeep Kumar Surisetty <psuriset>
Component: PerformanceAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED DUPLICATE QA Contact:
Severity: urgent Docs Contact:
Priority: urgent    
Version: 6.2.8CC: cduryee, inecas, jhutar, mmccune, pmoravec
Target Milestone: UnspecifiedKeywords: Performance
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: scale_lab
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-03-30 14:55:55 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
ruby memory growth while running 9k hosts
none
swapping while running 9k hosts
none
dynflow_executor memory growth while running 9k hosts
none
passenger-foreman memory growth while running 9k hosts
none
mem growth (date && ps aux --sort -rss | head -n20)
none
pgsql memory growth while running 9k hosts none

Description Pradeep Kumar Surisetty 2017-03-29 02:28:17 UTC
Description of problem:

Ruby, passenger-foreman memory is growing higher at scale.
We have registered till 9K with katello-agent. have plans to go larger scale

Ruby @ 50G, passenger-foreman @ 46G,  Dynflow_executor @ 9G
As shown in attached screenshots


satellite is running on KVM/Libvirt VM.  (24 vcpu, 64GB)
PassengerMaxPoolSize 24


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


How reproducible:


Steps to Reproduce:
1. Register hosts to satelite
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Pradeep Kumar Surisetty 2017-03-29 02:29:09 UTC
Created attachment 1267212 [details]
ruby memory growth while running 9k hosts

Comment 2 Pradeep Kumar Surisetty 2017-03-29 02:29:47 UTC
Created attachment 1267214 [details]
swapping while running 9k hosts

Comment 3 Pradeep Kumar Surisetty 2017-03-29 02:30:20 UTC
Created attachment 1267216 [details]
dynflow_executor memory growth while running 9k hosts

Comment 4 Pradeep Kumar Surisetty 2017-03-29 02:30:53 UTC
Created attachment 1267217 [details]
passenger-foreman memory growth while running 9k hosts

Comment 5 Pradeep Kumar Surisetty 2017-03-29 02:39:29 UTC
Created attachment 1267218 [details]
mem growth (date && ps aux --sort -rss | head -n20)

Comment 6 Pradeep Kumar Surisetty 2017-03-29 02:56:18 UTC
Created attachment 1267222 [details]
pgsql memory growth while running 9k hosts

Comment 7 Ivan Necas 2017-03-29 07:16:42 UTC
For dynflow memory growth, please follow https://bugzilla.redhat.com/show_bug.cgi?id=1412307#c25 to collect more data about the garbage collection runs and memory allocation

For passenger growth, I'm curious if this might be related to https://bugzilla.redhat.com/show_bug.cgi?id=1434040 and if we could compare the behaviour after applying the patches from there.

Comment 8 Ivan Necas 2017-03-29 07:49:44 UTC
Also, I would like to ask for export of the tasks related data to csv, using the script available in https://bugzilla.redhat.com/show_bug.cgi?id=1412307#c22, also for future uploads, as it contains very valuable data for further analysis.

Comment 10 Ivan Necas 2017-03-29 20:07:07 UTC
While investigating some tasks that took too long (host update), I've noticed
we were receiving a lot of docker interfaces from the hosts that run the containers and we spend a lot of time and memory when processing them.

This might be related to https://bugzilla.redhat.com/show_bug.cgi?id=1373903

Can you try adding 'veth*' to list of parsed interfaces in Provisioning -> "Ignore interfaces with matching identifier" (ignored_interface_identifiers)

Also I recommend cleaning the docker interfaces from database:

cat <<RUBY | foreman-rake console
Nic::Interface.where("identifier like ?", 'veth%').each { |i| i.delete }
RUBY

I would be interested into seeing how the memory behaves after that.

Another thing that might be related to this is https://bugzilla.redhat.com/show_bug.cgi?id=1435370

Comment 11 Jan Hutaƙ 2017-03-30 11:47:26 UTC
That magic with veth* interfaces worked nicely. Ruby RSS changed from about 34G to 19G. Thank you!

Comment 12 Ivan Necas 2017-03-30 14:55:55 UTC
Given we've seen the improvement, I'm closing this bug as duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1373903 and will propose for getting that for 6.2, to prevent this kind of hick-ups on customers running docker with sat

*** This bug has been marked as a duplicate of bug 1373903 ***