[pve-devel] [PATCH pve-common 1/1] ProcFSTools: add read_pressure

[Alexandre Derumier]

>>I have no idea how reliable this is, because we do not use cgroups v2.
But yes,
>>I think this would be useful.

I have tested it on a host with a lot of small vms. (something like 400vms
on  a 48cores), with this number of vms, they was a lot of context
switches, and vms was laggy.
cpu usage was ok (maybe 40%), loadaverage was around 40,  but pressure was
around 20%. (so it seem more precise than loadaverage)

global /proc/pressure/cpu   was almost the sum of cgroups of
/sys/fs/cgroup/unified/qemu.slice/<vmid>.scope/cpu.pressure

so,it seem reliable.

(I don't have lxc container in production, but I think it should be the
same)

So, yes, I think we could add them to rrd for both host/vms.


BTW, I'm currently playing with reading the rrd files, and I have notice
than lower precision is 1minute.
as pvestatd send values around each 10s,  is this 1minute precision an
average of 6x10s values send by pvestatd ?

I'm currently working on a poc of vm balancing, but I would like to have
something like 15min of 10s precision (90 samples of 10s).
So currently I'm getting stats each 10s manually
with PVE::API2Tools::extract_vm_stats like the ressource api.
(This use PVE::Cluster::rrd_dump , but I don't understand the ipcc_. code.
does it only return current streamed values?
 then after the rrdcached daemon is writing to rrd file the average values
each minute ?)

I don't known if we could have rrd files with 15min of 10s precision ?
(don't known the write load impact on disks)




Le mar. 13 oct. 2020 à 08:05, Dietmar Maurer <dietmar at proxmox.com> a écrit :

> > I have notice that it's possible to get pressure info for each vm/ct
> > through cgroups
> >
> > /sys/fs/cgroup/unified/qemu.slice/<vmid>.scope/cpu.pressure
> > /sys/fs/cgroup/unified/lxc/<vmid>/cpu.pressure
> >
> >
> > Maybe it could be great to have some new rrd graphs for each vm/ct ?
> > They are very useful counters to known a specific vm/ct is overloaded
>
> I have no idea how reliable this is, because we do not use cgroups v2. But
> yes,
> I think this would be useful.
>
>