High CPU Usage

[XenoBIT78]

---

BUG REPORT INFORMATION

/kind bug

Description
Running Fedoraserver 33

I only run one container and the container is working fine.. container CPU usages says 2-3%
but podman CPU usage says above 80% often around 100%. Even if i stop the container the CPU Usage stays high.

Podman installed from Official Fedora 33 Repo

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3244 root 20 0 9852.1m 104016 73728 S 1072 0.3 11591:55 podman
5456 server 20 0 8687484 90760 72248 S 898.3 0.3 8807:08 podman

Steps to reproduce the issue:

1. Start a container
2. Watch Cpu Usage go up

Output of podman version:
Version: 2.1.1
API Version: 2.0.0
Go Version: go1.15.2
Built: Wed Oct 7 18:21:20 2020
OS/Arch: linux/amd64

Output of podman info --debug:
host:
arch: amd64
buildahVersion: 1.16.1
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: conmon-2.0.21-3.fc33.x86_64
path: /usr/bin/conmon
version: 'conmon version 2.0.21, commit: 0f53fb68333bdead5fe4dc5175703e22cf9882ab'
cpus: 24
distribution:
distribution: fedora
version: "33"
eventLogger: journald
hostname: plex-server
idMappings:
gidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 65536
uidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 65536
kernel: 5.9.9-200.fc33.x86_64
linkmode: dynamic
memFree: 628035584
memTotal: 33663246336
ociRuntime:
name: crun
package: crun-0.15.1-1.fc33.x86_64
path: /usr/bin/crun
version: |-
crun version 0.15.1
commit: eb0145e5ad4d8207e84a327248af76663d4e50dd
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
os: linux
remoteSocket:
exists: true
path: /run/user/1000/podman/podman.sock
rootless: true
slirp4netns:
executable: /usr/bin/slirp4netns
package: slirp4netns-1.1.4-4.dev.giteecccdb.fc33.x86_64
version: |-
slirp4netns version 1.1.4+dev
commit: eecccdb96f587b11d7764556ffacfeaffe4b6e11
libslirp: 4.3.1
SLIRP_CONFIG_VERSION_MAX: 3
libseccomp: 2.5.0
swapFree: 2749624320
swapTotal: 4294963200
uptime: 23h 23m 25s (Approximately 0.96 days)
registries:
search:

• registry.fedoraproject.org
• registry.access.redhat.com
• registry.centos.org
• docker.io
  store:
  configFile: /home/server/.config/containers/storage.conf
  containerStore:
  number: 0
  paused: 0
  running: 0
  stopped: 0
  graphDriverName: overlay
  graphOptions:
  overlay.mount_program:
  Executable: /usr/bin/fuse-overlayfs
  Package: fuse-overlayfs-1.2.0-1.fc33.x86_64
  Version: |-
  fusermount3 version: 3.9.3
  fuse-overlayfs: version 1.1.0
  FUSE library version 3.9.3
  using FUSE kernel interface version 7.31
  graphRoot: /home/server/.local/share/containers/storage
  graphStatus:
  Backing Filesystem: xfs
  Native Overlay Diff: "false"
  Supports d_type: "true"
  Using metacopy: "false"
  imageStore:
  number: 0
  runRoot: /run/user/1000/containers
  volumePath: /home/server/.local/share/containers/storage/volumes
  version:
  APIVersion: 2.0.0
  Built: 1602087680
  BuiltTime: Wed Oct 7 18:21:20 2020
  GitCommit: ""
  GoVersion: go1.15.2
  OsArch: linux/amd64
  Version: 2.1.1
  `

Package info (e.g. output of rpm -q podman or apt list podman):
podman-2.1.1-12.fc33.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?
Yes

Additional environment details (AWS, VirtualBox, physical, etc.):
Physical server running AMD Ryzen 9 3900X 12-Core Processor

[Luap99]

Can you provide more details? What commands are you running? How often does it happen? Do you use the podman service?

[XenoBIT78]

happens all the time.. 5 mins after reboot cpu usage just starts climbing...
No i don't run the systemd service.. i start it from podman manager in Cockpit

podman run -d
--name=sonarr
-e PUID=983
-e PGID=983
-e TZ=Europe/Copenhagen
-e UMASK_SET=022
-p 8989:8989
-v /srv/.config/sonarr:/config
-v /srv/storage/tv:/tv
-v /srv/.config/mounts/download-cache/sonarr:/downloads
--restart unless-stopped
docker.io/linuxserver/sonarr:preview

[Luap99]

If you are using cockpit than you use the podman service. I think this a dup of #8050. A new version which should include the fix is planned to be released next week.