Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
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
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
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.
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
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