Bug 1393611 - hammer erratum list command taking too much time to display erratum
Summary: hammer erratum list command taking too much time to display erratum
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Hammer
Version: 6.2.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: Unspecified
Assignee: Tomas Strachota
QA Contact: jcallaha
URL:
Whiteboard:
Depends On: 1023127 1418412
Blocks: 1394365
TreeView+ depends on / blocked
 
Reported: 2016-11-10 00:53 UTC by Nagoor Shaik
Modified: 2020-04-15 14:49 UTC (History)
11 users (show)

Fixed In Version: rubygem-hammer_cli-0.5.1.13-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1394365 (view as bug list)
Environment:
Last Closed: 2017-03-06 08:34:19 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 17740 0 None None None 2016-12-19 15:27:49 UTC
Red Hat Product Errata RHBA-2017:0447 0 normal SHIPPED_LIVE Satellite 6.2.8 Async Bug Release 2017-03-06 13:23:41 UTC

Description Nagoor Shaik 2016-11-10 00:53:57 UTC
Description of problem:
hammer erratum list command taking too much time to display erratum, if there are 10+ repositories synchronized into Satellite 

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

How reproducible:
100%

Steps to Reproduce:
1. Synchronize 10 + Server RPMs and other repositories of different RHEL releases
2. Execute hammer erratum list which seems to be hung for a very long time and response/result is taking more than an hour to display i.e. time varies based upon the number of repositories it has to query.

Actual results:
With 10+ repositories time took to display the result was around 

real    69m32.042s
user    66m39.418s
sys     0m1.193s

Expected results:
Should display the result immediately as REST API of the same does.

Additional info:

If we query the same information through REST API, the results are pretty fast.

Comment 3 Tomas Strachota 2016-11-23 15:00:15 UTC
Nagoor,
could you please attach full output of hammer -d erratum list from the machine where you experienced the slowness? Thank you!

Comment 4 Mihir Lele 2016-12-04 11:19:38 UTC
Hello Tomas,

I have taken over this case from Nagoor.

I am attaching the full output of "# hammer -d erratum list --content-view "AMAT Certified RHEL 6 FY2017Q1 64-bit"" which was provided by the customer.

If you need anything else, let me know.

Regards,
Mihir

Comment 5 Mihir Lele 2016-12-04 11:20:20 UTC
Hello Tomas,

I have taken over this case from Nagoor.

I am attaching the full output of "# hammer -d erratum list --content-view "AMAT Certified RHEL 6 FY2017Q1 64-bit"" which was provided by the customer.

If you need anything else, let me know.

Regards,
Mihir

Comment 7 Tomas Strachota 2016-12-16 11:29:25 UTC
Thank you very much from the logs, Mihir. 

From the timestamps in the log it seems the complete data was fetched in 3 minutes and the rest of the time was hammer trying to print it:
- started:       2016-11-30 22:50:24
- last response: 2016-11-30 22:53:29
- time - real:              02:18:58
------------------------------------
- getting data took:        00:03:05
- print time:               02:15:53

It seems that printing tables is terribly suboptimal.

Comment 13 Bryan Kearney 2016-12-19 17:12:11 UTC
Upstream bug assigned to tstrachota

Comment 14 Bryan Kearney 2016-12-19 17:12:15 UTC
Upstream bug assigned to tstrachota

Comment 15 Bryan Kearney 2016-12-21 17:11:38 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/17740 has been resolved.

Comment 18 jcallaha 2017-02-21 15:47:07 UTC
Verified in Satellite 6.2.8 Snap 3

While there are no standards for errata count, the results below look like a significant improvement over the previous performance.

Satellite with 6,335 errata:
real	1m35.424s
user	0m11.889s
sys	0m0.714s

Satellite with 33,289 errata:
real	5m28.468s
user	0m39.740s
sys	0m1.505s

Comment 20 errata-xmlrpc 2017-03-06 08:34:19 UTC
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:0447


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