Bug#958883: unattended-upgrades pegs CPU at 100% for an extended period
Hi Balint,
I looked at the patch you link to
(https://github.com/mvo5/unattended-upgrades/pull/280) but the
unattended-upgrade code that is in the diff is fairly different from
what is in the version in Buster, specifically this chunk:
-if not marking_succeeded or \
- not check_changes_for_sanity(self, desired_pkg=pkg):
+if (not marking_succeeded
+or not check_changes_for_sanity(self, desired_pkg=pkg)) \
+and allow_marking_fallback():
logging.debug("falling back to adjusting %s's dependencies"
% pkg.name)
self.clear()
this class UnattendedUpgradesCache(apt.Cache) is in there, but it seems
fairly different and there is no 'if not marking_succeeded' in there at
all.
--
micah
Bug#958883: unattended-upgrades pegs CPU at 100% for an extended period
Hi Matt,
On Sat, Aug 1, 2020 at 12:03 AM Matt Taggart wrote:
>
> I am also seeing unattended upgrade consume 100% CPU. Attached is a
> image of the cpu usage that started upon upgrade to buster. Each time uu
> runs the system has 30-40mins of 100% cpu spinning.
>
> The system is running the current buster version, 1.11.2.
>
> I see:
> #958883 (this bug) - fixed in 2.4, might be the same issue?
> #899366 - fixed in 1.4
> #960966 - still open but strace seems different
>
> The last things I see in strace -f are:
>
>
> recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base=NULL,
> iov_len=0}], msg_iovlen=1, msg_controllen=0,
> msg_flags=MSG_CTRUNC|MSG_TRUNC|MSG_CMSG_CLOEXEC},
> MSG_PEEK|MSG_TRUNC|MSG_CMSG_CLOEXEC) = 20
> recvmsg(5, {msg_name={sa_family=AF_NETLINK, nl_pid=0,
> nl_groups=}, msg_namelen=128->12, msg_iov=[{iov_base={{len=20,
> type=NLMSG_DONE, flags=NLM_F_MULTI, seq=0, pid=31505}, 0}, iov_len=20}],
> msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CTRUNC|MSG_CMSG_CLOEXEC},
> MSG_CMSG_CLOEXEC) = 20
> brk(0x79c5000) = 0x79c5000
> brk(0x7a1f000) = 0x7a1f000
> mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7f257770d000
> mremap(0x7f257770d000, 1052672, 2101248, MREMAP_MAYMOVE) = 0x7f257750c000
> mremap(0x7f257750c000, 2101248, 4198400, MREMAP_MAYMOVE) = 0x7f257710b000
>
>
> I considered trying 2.5 from testing but it wants to pull in newer apt
> and some other things.
> Is a backport of 2.5 to buster possible for testing?
> Let me know if you want me to try anything.
> This seems important enough to fix in a stable update.
There were many performance-related fixes in unattended-upgrades. The
most significant ones need newer python-apt, so a potential backport
is blocked on a python-apt backport. Also while I'd be happy to
provide a backport at the moment I can't commit to maintaining one so
it needs a volunteer to do the unattended-upgrades backport.
If you are ok with running a patched version yourself there is a fix
in flight to disable the CPU intensive parts. Please read the change
carefully because it will keep more packages back:
https://github.com/mvo5/unattended-upgrades/pull/280
Cheers,
Balint
>
> --
> Matt Taggart
> tagg...@debian.org
>
--
Balint Reczey
Ubuntu & Debian Developer
Bug#958883: unattended-upgrades pegs CPU at 100% for an extended period
I am also seeing unattended upgrade consume 100% CPU. Attached is a
image of the cpu usage that started upon upgrade to buster. Each time uu
runs the system has 30-40mins of 100% cpu spinning.
The system is running the current buster version, 1.11.2.
I see:
#958883 (this bug) - fixed in 2.4, might be the same issue?
#899366 - fixed in 1.4
#960966 - still open but strace seems different
The last things I see in strace -f are:
recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base=NULL,
iov_len=0}], msg_iovlen=1, msg_controllen=0,
msg_flags=MSG_CTRUNC|MSG_TRUNC|MSG_CMSG_CLOEXEC},
MSG_PEEK|MSG_TRUNC|MSG_CMSG_CLOEXEC) = 20
recvmsg(5, {msg_name={sa_family=AF_NETLINK, nl_pid=0,
nl_groups=}, msg_namelen=128->12, msg_iov=[{iov_base={{len=20,
type=NLMSG_DONE, flags=NLM_F_MULTI, seq=0, pid=31505}, 0}, iov_len=20}],
msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CTRUNC|MSG_CMSG_CLOEXEC},
MSG_CMSG_CLOEXEC) = 20
brk(0x79c5000) = 0x79c5000
brk(0x7a1f000) = 0x7a1f000
mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f257770d000
mremap(0x7f257770d000, 1052672, 2101248, MREMAP_MAYMOVE) = 0x7f257750c000
mremap(0x7f257750c000, 2101248, 4198400, MREMAP_MAYMOVE) = 0x7f257710b000
I considered trying 2.5 from testing but it wants to pull in newer apt
and some other things.
Is a backport of 2.5 to buster possible for testing?
Let me know if you want me to try anything.
This seems important enough to fix in a stable update.
--
Matt Taggart
tagg...@debian.org
