Red Hat Bugzilla – Bug 1435370
uploading facts involves synchronous dynflow task, can cause bottleneck
Last modified: 2017-06-20 13:23:29 EDT
Description of problem: If a Satellite server is heavily loaded and has lots of tasks queued, you may start to see the web UI and API become unresponsive. Many of the passenger workers will be hung waiting on URLs like this: PUT /rhsm/consumers/<UUID> The root cause is that updating facts kicks off a synchronous dynflow task. If dynflow is backed up, client fact uploads will get slower and slower, eventually consuming all passenger workers. Version-Release number of selected component (if applicable): 6.2.8 Steps to Reproduce: 1. create a large number of tasks that have to be run 2. on a registered client, delete /var/lib/rhsm/facts/facts.json and run subscription-manager facts --update Actual results: slow response, possible timeouts Expected results: the client should get a reply quickly and the host update can then happen asynchronously. Note that if the async task fails, the client would not be aware.
Created attachment 1265824 [details] proposed patch to make host update async on fact upload
Created redmine issue http://projects.theforeman.org/issues/19061 from this bug
Upstream bug assigned to cduryee@redhat.com
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/19061 has been resolved.
Verified in satellite-6.2.10-1.0.el7sat.noarch, updating facts while running a remote job on 3000 hosts was done asynchronously without delay
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:1553