Bug 2387053

Summary:	fedpkg and ptyxis high CPU usage when running fedpkg new-sources with a big tarball
Product:	[Fedora] Fedora	Reporter:	Dominik 'Rathann' Mierzejewski <dominik>
Component:	fedpkg	Assignee:	Ondřej Nosek <onosek>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	42	CC:	belegdol, code, fweimer, kevin, lsedlar, mcatanza, onosek, ppisar, qcxhome
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	rpkg-1.69	Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2025-11-30 19:48:57 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Dominik 'Rathann' Mierzejewski 2025-08-07 11:30:53 UTC

Description of problem:
fedpkg causes(?) high CPU usage (1 core at 100% by fedpkg and 1 core at 100% by ptyxis) when running fedpkg new-sources big-tarball under ptyxis.

Version-Release number of selected component (if applicable):
fedpkg-1.46-4.fc42.noarch
ptyxis-48.4-2.fc42.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. fedpkg new-sources big-tarball (e.g. openapv)
2. check top output

Actual results:
Both fedpkg and ptyxis processes show 100% CPU usage.

Expected results:
Minimal CPU usage by both fedpkg and ptyxis.

Comment 1 Petr Pisar 2025-09-30 14:21:36 UTC

Does this happen in plain shell and terminal without the ptyxis container layer?

Comment 2 Florian Weimer 2025-09-30 15:02:26 UTC

Could you capture “strace -f -p … -o …” output while this is happening? I wonder if the progress indicator is over-active. Otherwise, maybe run an upload under “perf record”? I can try that myself if I remember when a new upload comes up.

Comment 3 Kevin Fenzi 2025-09-30 18:13:29 UTC

fedpkg -v new-sources might also show something?

Comment 4 Julian Sikorski 2025-09-30 19:41:33 UTC

I will be able to test this again next month once mame-0.282 is released. Or is there a possibility to re-upload an already uploaded file?
(In reply to Petr Pisar from comment #1)
> Does this happen in plain shell and terminal without the ptyxis container
> layer?

Would gnome-terminal work?

Comment 5 Petr Pisar 2025-10-01 07:50:48 UTC

(In reply to Julian Sikorski from comment #4)
> Or is there a possibility to re-upload an already uploaded file?

No, the server checks a hash of the file.

> (In reply to Petr Pisar from comment #1)
> > Does this happen in plain shell and terminal without the ptyxis container
> > layer?
> 
> Would gnome-terminal work?

Yes.

Comment 6 Ben Beasley 2025-10-01 10:11:20 UTC

(In reply to Florian Weimer from comment #2)
> Could you capture “strace -f -p … -o …” output while this is happening? I
> wonder if the progress indicator is over-active. Otherwise, maybe run an
> upload under “perf record”? I can try that myself if I remember when a new
> upload comes up.

It does appear that the system calls are dominated by overly-frequent progress-bar updates, e.g.:

1389366 write(1, "\r###############################"..., 79) = 79
1389366 rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_ONSTACK}, NULL, 8) = 0
1389366 ppoll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, {tv_sec=0, tv_nsec=0}, NULL, 0) = 0 (Timeout)
1389366 rt_sigaction(SIGPIPE, NULL, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_ONSTACK}, 8) = 0
1389366 rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_ONSTACK}, NULL, 8) = 0
1389366 recvfrom(4, 0xaaab27f4e5c3, 5, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
1389366 ioctl(1, TCGETS, {c_iflag=ICRNL|IXON|IUTF8, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
1389366 write(1, "\r###############################"..., 79) = 79
1389366 ioctl(1, TCGETS, {c_iflag=ICRNL|IXON|IUTF8, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
1389366 write(1, "\r###############################"..., 79) = 79
1389366 rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_ONSTACK}, NULL, 8) = 0
1389366 ppoll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, {tv_sec=0, tv_nsec=0}, NULL, 0) = 0 (Timeout)
1389366 rt_sigaction(SIGPIPE, NULL, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_ONSTACK}, 8) = 0
1389366 rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_ONSTACK}, NULL, 8) = 0
1389366 recvfrom(4, 0xaaab27f4e5c3, 5, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
1389366 ioctl(1, TCGETS, {c_iflag=ICRNL|IXON|IUTF8, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
1389366 write(1, "\r###############################"..., 79) = 79
1389366 ioctl(1, TCGETS, {c_iflag=ICRNL|IXON|IUTF8, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
1389366 write(1, "\r###############################"..., 79) = 79
1389366 rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_ONSTACK}, NULL, 8) = 0
1389366 ppoll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, {tv_sec=0, tv_nsec=0}, NULL, 0) = 0 (Timeout)
1389366 rt_sigaction(SIGPIPE, NULL, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_ONSTACK}, 8) = 0
1389366 rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_ONSTACK}, NULL, 8) = 0
1389366 recvfrom(4, 0xaaab27f4e5c3, 5, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
1389366 ioctl(1, TCGETS, {c_iflag=ICRNL|IXON|IUTF8, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
1389366 write(1, "\r###############################"..., 79) = 79
1389366 ioctl(1, TCGETS, {c_iflag=ICRNL|IXON|IUTF8, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0

Comment 7 Ben Beasley 2025-10-01 10:46:00 UTC

I proposed https://pagure.io/rpkg/pull-request/755 to fix this.

Comment 8 Ben Beasley 2025-11-30 19:48:57 UTC

My suggested fix was merged upstream and released in rpkg 1.69, https://docs.pagure.org/rpkg/releases/1.69.html#lookaside-upload-download-progress-bar-changes. This should be fixed in https://bodhi.fedoraproject.org/updates/FEDORA-2025-fb2a917076 for F43, and in corresponding updates now in updates-testing for other releases.