Very high pvestatd CPU usage

T

tachi

New Member
Aug 15, 2026
2
0
1
Italy
andrea.pappacoda.it
Hi all, I'm very new here so sorry if this is a dumb thread :)

I was looking at the CPU time used by the processes on my Proxmox host, and I noticed that over the last 90 days the `pvestatd` daemon used 5 days and a half of CPU time:

Code: 
# systemctl status pvestatd.service
● pvestatd.service - PVE Status Daemon
     Loaded: loaded (/usr/lib/systemd/system/pvestatd.service; enabled; preset: enabled)
     Active: active (running) since Fri 2026-05-15 00:33:08 CEST; 3 months 1 day ago
 Invocation: 3f4af53f2a9d402e9e42efa70a0b06ce
   Main PID: 2123 (pvestatd)
      Tasks: 1 (limit: 25811)
     Memory: 129.3M (peak: 252M)
        CPU: 5d 12h 44min 51.985s
     CGroup: /system.slice/pvestatd.service
             └─2123 pvestatd

This much CPU time for a built-in daemon looks a bit much, especially as the only other thing on the system which comes close to this is the OPNsense VM firewalling the network (pve-firewall is disabled/stopped).

There are 19 virtual machines running on the host, and 17 of them are LXCs.

Does anyone have an idea of what may be going on here? How can I reduce the amount of resources consumed by the status daemon?

Thanks! Bye :)
 
The usual cause of elevated pvestatd CPU is storage polling, it stats every configured storage on each cycle.

Check whether it's logging timeouts:
journalctl -u pvestatd --since "7 days ago" | grep -iE 'timeout|unable|got status'

And see what it's using right now rather than cumulatively:
top -b -n2 -d5 -p $(pgrep -x pvestatd) | tail -5

If the live figure is a few percent and there are no timeouts, this is just normal behaviour on a busy host.
 
Hi Johnnie, thanks for the reply :)

JohnnieKF said:
The usual cause of elevated pvestatd CPU is storage polling, it stats every configured storage on each cycle.

Check whether it's logging timeouts:
journalctl -u pvestatd --since "7 days ago" | grep -iE 'timeout|unable|got status'
Click to expand...

Not much to see from the journal. I have rebooted the machine since (yesterday at 17:12), but the behaviour is exactly the same (more than one hour of CPU time for 19 hours of uptime):

Code: 
# journalctl --no-hostname --unit pvestatd.service --boot
Aug 15 17:12:29 systemd[1]: Starting pvestatd.service - PVE Status Daemon...
Aug 15 17:12:29 pvestatd[2083]: starting server
Aug 15 17:12:29 systemd[1]: Started pvestatd.service - PVE Status Daemon.
Aug 15 17:12:43 pvestatd[2083]: modified cpu set for lxc/103: 0-1
Aug 15 17:12:43 pvestatd[2083]: modified cpu set for lxc/104: 0
Aug 15 17:12:43 pvestatd[2083]: modified cpu set for lxc/105: 0-1
Aug 15 17:12:43 pvestatd[2083]: modified cpu set for lxc/106: 0
Aug 15 17:12:43 pvestatd[2083]: modified cpu set for lxc/107: 0
Aug 15 17:12:43 pvestatd[2083]: modified cpu set for lxc/108: 0
Aug 15 17:12:43 pvestatd[2083]: modified cpu set for lxc/110: 0
Aug 15 17:12:43 pvestatd[2083]: modified cpu set for lxc/103: 2-3
Aug 15 17:12:43 pvestatd[2083]: modified cpu set for lxc/104: 1
Aug 15 17:12:43 pvestatd[2083]: modified cpu set for lxc/105: 2,4
Aug 15 17:12:43 pvestatd[2083]: modified cpu set for lxc/106: 1
Aug 15 17:12:43 pvestatd[2083]: modified cpu set for lxc/107: 3
Aug 15 17:12:43 pvestatd[2083]: modified cpu set for lxc/108: 5
Aug 15 17:12:48 pvestatd[2083]: status update time (8.535 seconds)
Aug 15 17:12:52 pvestatd[2083]: modified cpu set for lxc/103: 6-7
Aug 15 17:12:52 pvestatd[2083]: modified cpu set for lxc/105: 0,2
Aug 15 17:12:52 pvestatd[2083]: modified cpu set for lxc/108: 0
Aug 15 17:12:52 pvestatd[2083]: modified cpu set for lxc/110: 2
Aug 15 17:12:52 pvestatd[2083]: modified cpu set for lxc/113: 0,3
Aug 15 17:12:52 pvestatd[2083]: modified cpu set for lxc/115: 6
Aug 15 17:12:52 pvestatd[2083]: modified cpu set for lxc/116: 7
Aug 15 17:12:52 pvestatd[2083]: modified cpu set for lxc/117: 1,5
Aug 15 17:12:57 pvestatd[2083]: status update time (7.690 seconds)
Aug 15 17:12:59 pvestatd[2083]: modified cpu set for lxc/118: 0,5
Aug 15 17:12:59 pvestatd[2083]: modified cpu set for lxc/120: 1
Aug 15 17:12:59 pvestatd[2083]: modified cpu set for lxc/121: 2
Aug 15 17:13:09 pvestatd[2083]: modified cpu set for lxc/104: 3
Aug 15 17:13:09 pvestatd[2083]: modified cpu set for lxc/105: 2,5
Aug 15 22:36:51 pvestatd[2083]: auth key pair too old, rotating..
Aug 16 04:01:36 pvestatd[2083]: status update time (6.385 seconds)
Aug 16 04:20:35 pvestatd[2083]: status update time (6.419 seconds)
Aug 16 04:20:46 pvestatd[2083]: status update time (6.162 seconds)
Aug 16 04:20:55 pvestatd[2083]: status update time (6.642 seconds)

JohnnieKF said:
And see what it's using right now rather than cumulatively:
top -b -n2 -d5 -p $(pgrep -x pvestatd) | tail -5

If the live figure is a few percent and there are no timeouts, this is just normal behaviour on a busy host.
Click to expand...

This is not really what I'm interested about. Of course, at any point the daemon may not be doing much (which could very well be the moment in which I run the top command you mention), but at some other points it may be very busy. If cumulatively the monitoring daemon **alone** accounts for as much as the virtual machine doing most of the actual work, then it looks problematic to me.

P.S. the reboot I mention was in order to update to PVE 9.2.10, but the issue persisted
 
Last edited:
The pvestatd daemon does a lot of background work, like checking the cluster/node/storage/LXC/VM status, or when to run ballooning and for whom. Then it collects statistics that need to be written to rrd databases (broadcast to other nodes) and some housekeeping. You need it, our cluster is small, but we have 1 1/2 days of CPU time within 3 weeks already, hence the busier the node the more pvestatd will need to do.
 
You must log in or register to reply here.
Top Bottom
Back