Issue #1947
closed
Concurrent sync of repos is running slow
Description
Concurrently doing a pulp to pulp sync with certain repos is running very slow and the celery workers are running %100 during the sync
The repos are:
Red Hat Enterprise Linux 5 Server RPMs i386 5Server
Red Hat Enterprise Linux 6 Server RPMs x86_64 5Server
Red Hat Enterprise Linux 5 Server RPMs i386 5Server
Red Hat Enterprise Linux 6 Server RPMs x86_64 5Server
Red Hat Enterprise Linux 7 Server RPMs x86_64 5Server
One repo seems to take longer than others:
9059 seconds (~150 mins)
Default_Organization-DEV-rhel-6-server-x86_64-cv-Red_Hat_Enterprise_Linux_Server-Red_Hat_Enterprise_Linux_6_Server_RPMs_x86_64_6Server
Unsure if that specific repo is affecting the sync, I attached the output from pulp for that particular sync.
Files
Related issues
Updated by jomitsch@redhat.com almost 8 years ago
- Subject changed from Concurrent sync of repos causing celery workers to reach 100% cpu to Concurrent sync of repos are running slow
Updated by jomitsch@redhat.com almost 8 years ago
- Subject changed from Concurrent sync of repos are running slow to Concurrent sync of repos is running slow
Updated by bmbouter almost 8 years ago
We decided to defer triaging this until there is more info on a reproducer. @jcline suspects this is related to Errata processing and @smyers suggests it could be related to duplicate NEVRA searching. You can talk with them on IRC some more as you work up the reproducer.
Updated by mhrivnak almost 8 years ago
- Is duplicate of Issue #1949: re-publish takes longer than expected added
Updated by mhrivnak almost 8 years ago
- Status changed from NEW to CLOSED - DUPLICATE
Updated by lzap@redhat.com almost 8 years ago
Guys, this is annoying bug for Satellite. I see this was closed as dupe of "republish" bug, but I am seeing this with new repositories as well.
I am able to reproduce anytime with parallel sync of about 30 repositories with Satellite 6.2 beta2, contact me for details.
Updated by bmbouter almost 8 years ago
This is a duplicate bug. The actual bug is #1949 and is at ASSIGNED.
.