Bug 1436918 - Ruby, passenger-foreman memory is growing huge at scale.
Summary: Ruby, passenger-foreman memory is growing huge at scale.
Keywords:
Status: CLOSED DUPLICATE of bug 1373903
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Performance
Version: 6.2.8
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact:
URL:
Whiteboard: scale_lab
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-29 02:28 UTC by Pradeep Kumar Surisetty
Modified: 2020-09-10 10:23 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-30 14:55:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
ruby memory growth while running 9k hosts (48.27 KB, image/png)
2017-03-29 02:29 UTC, Pradeep Kumar Surisetty
no flags Details
swapping while running 9k hosts (79.62 KB, image/png)
2017-03-29 02:29 UTC, Pradeep Kumar Surisetty
no flags Details
dynflow_executor memory growth while running 9k hosts (96.54 KB, image/png)
2017-03-29 02:30 UTC, Pradeep Kumar Surisetty
no flags Details
passenger-foreman memory growth while running 9k hosts (100.83 KB, image/png)
2017-03-29 02:30 UTC, Pradeep Kumar Surisetty
no flags Details
mem growth (date && ps aux --sort -rss | head -n20) (14.34 KB, text/plain)
2017-03-29 02:39 UTC, Pradeep Kumar Surisetty
no flags Details
pgsql memory growth while running 9k hosts (65.30 KB, image/png)
2017-03-29 02:56 UTC, Pradeep Kumar Surisetty
no flags Details

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 ***


Note You need to log in before you can comment on or make changes to this bug.