Bug 1414159 - candlepin event listener can cause high system load when there are lots of incoming messages
Summary: candlepin event listener can cause high system load when there are lots of in...
Status: CLOSED DUPLICATE of bug 1431783
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Subscription Management
Version: 6.2.6
Hardware: Unspecified
OS: Unspecified
Target Milestone: Unspecified
Assignee: Eric Helms
QA Contact: jcallaha
Depends On:
Blocks: 1479962
TreeView+ depends on / blocked
Reported: 2017-01-17 22:25 UTC by Chris Duryee
Modified: 2018-02-19 16:23 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-07-31 19:33:57 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 18119 0 Normal New candlepin event queue is not de-duplicated during processing, causing large numbers of events to fire 2020-12-16 21:07:09 UTC

Description Chris Duryee 2017-01-17 22:25:11 UTC
Description of problem:

During mass registrations of systems, the candlepin event listener can get flooded with updates. If there are a large number of events coming in, it will fire lots of calls to candlepin for updated pool info, which can tax the system and cause performance issues. Eventually, these get expressed as DB locks:

2017-01-17 00:11:20 UTC STATEMENT:  UPDATE "katello_pools" SET "consumed" = $1, "updated_at" = $2 WHERE "katello_pools"."id" = 5
2017-01-17 00:11:23 UTC LOG:  process 44158 acquired ShareLock on transaction 76129721 after 4032.569 ms

There are probably a number of ways to fix this, but one way would be for the listener to read 100 messages at a time, de-duplicate them, then fire events for the pools that need updating. Additionally, it may make sense to only have the listener poll every 5 seconds in order to get more data queued up that can be de-duplicated.

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

How reproducible: often

Steps to Reproduce:
1. register 30K or more systems
2. attempt a mass registration at about one system every 2 seconds for 1 hour

Actual results: db locks, postgres slowness, and high candlepin load

Expected results: system should cope with registrations

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