Bug 973784 - copy performance with recursive option needs improvement
copy performance with recursive option needs improvement
Status: CLOSED CURRENTRELEASE
Product: Pulp
Classification: Community
Component: rpm-support (Show other bugs)
2.2 Beta
Unspecified Unspecified
medium Severity medium
: ---
: 2.4.0
Assigned To: Michael Hrivnak
Preethi Thomas
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-12 14:03 EDT by Michael Hrivnak
Modified: 2014-08-09 02:55 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-08-09 02:55:22 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of top/ps axf (16.53 KB, text/plain)
2014-06-03 12:31 EDT, Preethi Thomas
no flags Details

  None (edit)
Description Michael Hrivnak 2013-06-12 14:03:15 EDT
copy performance with the recursive option is slower than desirable. For example, on my machine, copying the RPMs for a rhel6 repo with about 10350 packages took 38 minutes. There are opportunities for optimization that should be explored, such as loading the list of source-side content only once.
Comment 1 Partha Aji 2013-10-10 11:48:52 EDT
A similar issue was found when I had a filter to unit copy all the kernel* packages in a RHEL repo with recursive. The total number copied over was 379 rpms out of 11K rpms. But the time taken was ~64 minutes on my machine. To put this in perspective, the time without the recursive on was ~11 seconds. 
The recursive option is pretty important for Katello's whitelist filters and hoping this gets improved before the next release.
Comment 2 Michael Hrivnak 2014-02-25 10:33:58 EST
This is a related change that will help copy performance in general, and performance of many other operations: https://github.com/pulp/pulp/pull/813
Comment 3 Michael Hrivnak 2014-02-27 08:38:53 EST
https://github.com/pulp/pulp_rpm/pull/453
Comment 4 Jeff Ortel 2014-04-03 09:36:24 EDT
build: 2.4.0-0.7.beta
Comment 5 Preethi Thomas 2014-06-03 12:29:44 EDT
failing 

Copy with recursive took very long. I am attaching the output of top/log etc

[root@dell-pesc430-03 ~]# time pulp-admin rpm repo copy rpm -f rhel6-5 -t rhel-copy1  --recursive 
This command may be exited via ctrl+c without affecting the request.


[-]
Running...
[/]
Running...

Task Failed

Pulp exception occurred: PulpExecutionException


real	73m5.131s
user	1m25.817s
sys	0m4.431s
Comment 6 Preethi Thomas 2014-06-03 12:31:31 EDT
Created attachment 901861 [details]
Output of top/ps axf
Comment 7 Preethi Thomas 2014-06-04 09:33:14 EDT
This could be that the system ran out of memory.

I did another repo copy on the same rhel6.5 repo on a different server and it completed with the following stat. I was running top, I did see the cpu close to 100% while the copy was running. But memory did not seem as high as the other (was below 10%)

[root@ibm-x3550m3-08 ~]# time pulp-admin rpm repo copy rpm -f rhel6-5 -t rhel65-copy --recursive 
This command may be exited via ctrl+c without affecting the request.


[/]
Running...

Copied:
  rpm: 12570


real	19m5.497s
user	0m17.457s
sys	0m0.917s
Comment 8 Michael Hrivnak 2014-06-13 16:54:11 EDT
https://github.com/pulp/pulp_rpm/pull/513
Comment 9 Randy Barlow 2014-06-17 15:02:35 EDT
Fixed in 2.4.0-0.21.beta.
Comment 10 Preethi Thomas 2014-06-25 14:35:43 EDT
Moving to verified
[root@ibm-x3550m3-10 ~]# rpm -qa pulp-server
pulp-server-2.4.0-0.21.beta.el6.noarch
[root@ibm-x3550m3-10 ~]# 

Recursive copy has gotten super fast!
[root@ibm-x3550m3-10 ~]# time pulp-admin rpm repo copy rpm -f rhel6-5 -t rhel65-copy --recursive 
This command may be exited via ctrl+c without affecting the request.


[-]
Running...

Copied:
  rpm: 12602


real	3m44.624s
user	0m6.992s
sys	0m0.256s
Comment 11 Randy Barlow 2014-08-09 02:55:22 EDT
This has been fixed in Pulp 2.4.0-1.

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