Red Hat Bugzilla – Bug 1526473
Large MiqServer process leads to large generic workers that get killed
Last modified: 2018-02-28 08:11:30 EST
Note, the changes to use unique set size (USS) instead of proportional set size (PSS) don't fix the server leaking. We now will not penalize workers for inheriting a large amount of memory from a large miq server process when they're forked. top will still show these workers as high memory usage (RSS) if they inherited memory from a large server. You need to use tools such as smem, smem -P MIQ, to see the USS. bin/rake evm:status will show the USS value now. We will continue to track down and fix the server memory growth but at least now, we won't be prematurely killing workers.
New commit detected on ManageIQ/manageiq-gems-pending/fine: https://github.com/ManageIQ/manageiq-gems-pending/commit/d51285ca19c96304c7e3b521ae16713d75cfcee1 commit d51285ca19c96304c7e3b521ae16713d75cfcee1 Author: Joe Rafaniello <jrafanie@redhat.com> AuthorDate: Mon Nov 13 16:26:26 2017 -0500 Commit: Joe Rafaniello <jrafanie@redhat.com> CommitDate: Fri Dec 15 11:20:13 2017 -0500 Store unique set size (USS) in the PSS column https://bugzilla.redhat.com/show_bug.cgi?id=1479356 Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1526473 Unique set size is a better way to detect workers that are growing unbounded since any memory/reference leaks would be shown in their uss. If the server process is large when forking, new workers would inherit a big pss immediately. We should really rename the column/hash key to uss. lib/gems/pending/util/miq-process.rb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Verified on 5.8.3.1.
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/RHSA-2018:0374