Red Hat Bugzilla – Bug 1393611
hammer erratum list command taking too much time to display erratum
Last modified: 2017-04-26 06:35:16 EDT
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.
Nagoor, could you please attach full output of hammer -d erratum list from the machine where you experienced the slowness? Thank you!
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.
Upstream bug assigned to tstrachota@redhat.com
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/17740 has been resolved.
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