Story #2434
closed
Add timing output to sync task steps
0%
Description
There are times with Pulp syncs take a long time with no clear understanding of which step(s) took abnormally long to complete. An example progress report can be seen below.
This is a request to add start and finish times to the individual steps (e.g. comps, purge_duplicates, errata) so that tasks can be analyzed for errant behavior. This is useful for debugging a singular sync that has gone awry as well as to bulk analyze systematic issues across a number of Pulp syncs. This could help identify issues with the underlying host and resources, Pulp itself or potential performance issues with the code for a given step.
progress_report:
yum_importer:
content:
items_total: 0
state: FINISHED
error_details: []
details:
rpm_total: 0
rpm_done: 0
drpm_total: 0
drpm_done: 0
size_total: 0
size_left: 0
items_left: 0
comps:
state: FINISHED
purge_duplicates:
state: FINISHED
distribution:
items_total: 0
state: FINISHED
error_details: []
items_left: 0
errata:
state: FINISHED
metadata:
state: FINISHED
Added by dkliban@redhat.com about 8 years ago
Updated by ehelms@redhat.com about 8 years ago
I should add, that this would be useful for ALL tasks to have more timing output included in them, sync is a major task and the one in particular I ran into this with.
Updated by ehelms@redhat.com about 8 years ago
I think the cProfiles will help, however, they have to be enabled to do any good, take my most recent encounter where I had to restart to enable them and for now that has fixed things, so its a waiting game to see the issue come up again, I could still see the timings being useful as it would show me which step is taking the longest and over time potentially identify a step that is taking too long when viewing the task from our UIs, if the profiling can be integrated to achieve this then that would work for me too
Updated by bizhang about 8 years ago
- Tracker changed from Issue to Story
- % Done set to 0
Updated by bmbouter over 5 years ago
- Status changed from NEW to CLOSED - WONTFIX
Updated by bmbouter over 5 years ago
Pulp 2 is approaching maintenance mode, and this Pulp 2 ticket is not being actively worked on. As such, it is being closed as WONTFIX. Pulp 2 is still accepting contributions though, so if you want to contribute a fix for this ticket, please reopen or comment on it. If you don't have permissions to reopen this ticket, or you want to discuss an issue, please reach out via the developer mailing list.
.
Changes how pulp-selinux RPM decides when to run restorecon statements
RHEL 7.3 was experiencing a bug that was preventing the pulp-selinux RPM from using semodule -l to figure out the installed version of pulp-selinux policies during upgrades. This patch switched to using rpm -qa for determining the version of previously installed SELinux policy.
The version comparison logic in relabel.sh only worked for version strings <= 1.9.z. This patch improves this code to make sure upgrades to 2.10.2 don't accidently run unnecesary restorecon statements.
closes #2434 https://pulp.plan.io/issues/2424