docker stats命令中容器的实际CPU使用量是多少

我正在docker swarm节点上运行postgres timescaledb。我将CPU限制设置为4，Mem限制设置为32G。当我检查docker stats时，我可以看到以下输出：

CONTAINER ID   NAME                                                                                     CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
c6ce29c7d1a4   pg-timescale.1.6c1hql1xui8ikrrcsuwbsoow5                                                 341.33%   20.45GiB / 32GiB      63.92%    6.84GB / 5.7GB    582GB / 172GB     133

CPU%在400%左右波动。节点有6个CPU，平均负载为1-2（1分钟平均负载），因此根据我的说法，在CPU-4的限制下，最大负载应该在6左右。我当前的负载是20（1分钟平均负载），postgres内部的

top

命令输出显示50-60%

我的服务配置限制：

deploy:
  resources:
    limits:
      cpus: '4'
      memory: 32G

---

我很困惑，所有的值都是不同的，那么postgres的实际CPU使用情况是什么？如何限制它？我的服务器负载被推到最大，即使postgres的限制设置为4。在postgres内部，我可以从htop中看到有6个内核和64G内存，所以它看起来拥有所有主机资源。根据docker stats，最大cpu为400%-corelate，限制为4个cpu。

Linux中的

top

等命令的平均负载指的是在一段时间内平均运行或等待运行的进程数。docker使用的CPU限制指定cgroup内进程允许的某个时间范围内的CPU周期数。这些并不是真正衡量同一件事，特别是当你考虑到I/O等待等因素时。您可以让一个进程等待从磁盘读取数据，该进程想要运行，但在I/O调用中被阻塞，从而增加主机上的负载测量值，但不使用任何CPU周期

当计算CPU分配给C组的数量时，不仅需要对进程的I/O和其他系统需求进行考虑，而且在CPU上接近饱和时考虑排队论。CPU的利用率越接近100%，准备运行的进程队列就可能越长，从而导致负载测量的显著跳跃

---

正确设置这些限制可能需要反复试验，因为并非所有进程都相同，主机上的所有工作负载也不相同。不定期启动并使驱动器和网络饱和的批处理作业将对主机产生与CPU和内存严重受限的科学计算截然不同的影响。

“平均负载为1-2”。。。“我的当前负载是20”1-2什么和20什么根据什么？包括运行命令及其输出。抱歉，我更新了问题。1m的平均负载。OS

平均负载示例：17,52,14,80,12,60

平均负载与cpu无关。这是一个实时进程计数。而且在负载方面不明显。