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.
Does this happen in plain shell and terminal without the ptyxis container layer?
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.
fedpkg -v new-sources might also show something?
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?
(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.
(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
I proposed https://pagure.io/rpkg/pull-request/755 to fix this.
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.