标签: cgroups
使用Cgroup来限制CPU使用率
我试图使用cgroups来限制CPU使用率.我正在使用本指南 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/sec-cpu_and_memory-use_case.html
我的/etc/cgconfig.conf文件如下
mount {
cpu = /mnt/cgroup/cpu,cpuacct;
cpuacct = /mnt/cgroup/cpu,cpuacct;
}
group wheel {
cpu {
cpu.shares="800";
}
cpuacct {
cpuacct.usage="0";
}
}
group test1 {
cpu {
cpu.shares="200";
}
cpuacct {
cpuacct.usage="0";
}
}
我的cgrules.conf如下
@wheel cpu,cpuacct wheel
@test1 cpu,cpuacct test1
当我尝试跑步时:
dd if=/dev/zero of=/dev/null bs=1024k
我看到用户100%的CPU使用率属于组轮和test1
我已经检查了服务cgconfig状态的服务并且已启动
Loaded: loaded (/usr/lib/systemd/system/cgconfig.service; disabled)
Active: active (exited) since Mon 2015-03-02 17:29:19 EET; 7min ago
Process: 1240 ExecStop=/usr/sbin/cgclear -l /etc/cgconfig.conf -e (code=exited, status=3)
Process: 56536 ExecStart=/usr/sbin/cgconfigparser -l /etc/cgconfig.conf -s 1664 (code=exited, …推荐指数
解决办法
查看次数
Docker容器中的内存限制和CPU限制
更新：
在关于此主题的stackoverflow上发现了很多问题和讨论。尽管它们被标记为已接受答案，并已被成千上万的用户开始使用，但在这里似乎并不是正确的答案。
我运行了一个具有资源限制的docker（版本1.13.1，版本092cba3）容器，如下所示：
docker run --privileged -v /sys/fs/cgroup:/sys/fs/cgroup -m 4096M --cpuset-cpus='0' --cpus=1 --cpu-shares=256 -p $IMAGE_NAME
主机系统（RHEL 7）具有4核和8G内存。基本上，我想限制容器的可用内存和CPU。成功启动容器后，我打开了bash并尝试从容器内查找限制信息。但是我无法获得正确的信息。
我尝试了这个：
sudo cat /proc/meminfo
结果是：
主机系统
内存总数：8008812 kB内存可用量：7416404 kB内存可用量：7537332 kB
Docker容器
内存总量：8008812 kB内存可用量：7318052 kB内存可用量：7498764 kB
同样，我想获得CPU限制：
grep -c ^processor /proc/cpuinfo
结果是：
主机系统 4
Docker映像 4
似乎容器不可见由容器强制执行的CPU和内存限制。我也尝试查询cgroup信息。
mkdir -p /tmp/memory
mount -n -t cgroup -o memory cgroup /tmp/memory
然后我看一下cgroup文件：
[root@engrlab memory]# cat /tmp/memory/memory.limit_in_bytes
9223372036854771712
该数字大于主机系统的实际内存。
有没有办法验证是否在容器中正确设置了资源约束？如何从容器中找到资源约束信息？感谢任何建议。
推荐指数
解决办法
查看次数
container_memory_working_set_bytes 与 process_resident_memory_bytes 和total_rss 之间的关系
我希望了解以下关系
container_memory_working_set_bytes vs process_resident_memory_bytes vs Total_rss (container_memory_rss) + file_mapped以便更好地装备系统以对 OOM 可能性进行警报。
如果容器/pod 运行单个进程来执行用 Go 编写的编译程序，这似乎违背了我的理解（现在让我感到困惑） 。
为什么两者之间的差异container_memory_working_set_bytes如此之大（接近10倍）process_resident_memory_bytes
container_memory_working_set_bytes而且和之间的关系在这里很奇怪，这是我读完container_memory_rss + file_mapped之后没有想到的
匿名和交换缓存内存总量（包括透明大页），它等于 memory.status 文件中的total_rss 值。不应将其与真实驻留集大小或 cgroup 使用的物理内存量相混淆。rss + file_mapped 将为您提供 cgroup 的驻留集大小。它不包括换出的内存。它确实包含来自共享库的内存，只要这些库中的页面实际上位于内存中。它确实包括所有堆栈和堆内存。
因此，cgroup总驻留集大小是rss + file_mapped如何小于container_working_set_bytes给定 cgroup 中运行的容器的值的
这让我觉得这个统计数据有些不正确。
以下是用于构建上图的 PROMQL
- process_resident_memory_bytes{container="sftp-downloader"}
- container_memory_working_set_bytes{container="sftp-downloader"}
- go_memstats_heap_alloc_bytes{container="sftp-downloader"}
- 容器_内存_映射_文件{容器=“sftp-downloader”} + 容器_内存_rss{容器=“sftp-downloader”}
推荐指数
解决办法
查看次数
LXC没有chroot
有没有办法在不创建容器的情况下使用LXC进行资源管理？我正在开发一个在沙盒中运行任意代码的服务,我只对硬件资源管理感兴趣.我不想要任何chrooting; 我只是希望这些进程组能够访问主文件系统.
我被告知lxc重量很轻,但我看到的所有示例都为每个lxc进程创建了一个新的容器(即带有完整操作系统的dir).我真的没有看到它比其他任何VM解决方案都轻得多.
那么有没有什么方法可以用LXC来控制和管理多个进程组,而无需为每个进程组创建单独的容器？
推荐指数
解决办法
查看次数
为Kubernetes中的pod分配或限制资源？
Pod的资源限制已设置为:
resource
limit
cpu: 500m
memory: 5Gi
并且10G在节点上留下了mem.
我5成功地在短时间内创建了pod,节点可能还剩下一些内存,例如8G.
随着时间的推移,mem的使用越来越多,并且达到limit(5G x 5 = 25G > 10G),然后节点就会没有响应.
为了确保可用性,有没有办法在节点上设置资源限制？
更新
核心问题是pod内存使用并不总是等于限制,特别是在它刚刚启动时.因此,可以尽快创建无限的pod,然后使所有节点满载.这不好.可能有一些东西要分配资源而不是设置限制.
更新2
我再次测试了限制和资源:
resources:
limits:
cpu: 500m
memory: 5Gi
requests:
cpu: 500m
memory: 5Gi
总内存为15G,剩余14G,但3个pod已安排并成功运行:
> free -mh
total used free shared buff/cache available
Mem: 15G 1.1G 8.3G 3.4M 6.2G 14G
Swap: 0B 0B 0B
> docker stats
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O
44eaa3e2d68c 0.63% 1.939 …推荐指数
解决办法
查看次数
如何检查进程是否在 docker 容器内运行（cgroup v2 linux 主机）
如何检查进程是否正在 Docker 容器内运行？我想要一种可靠且面向未来的方法。
这个问题已经在如何确定进程是否在 lxc/Docker 中运行？，但是答案相当旧，并且它似乎不适用于最近的设置（启用了 cgroups v2 的 Linux 主机、Docker 20.10.x、内核 5.10.x）。
评价最高的答案（来自上面的链接）建议检查docker中的字符串/proc/1/cgroup，但是这是我得到的：
# cat /proc/1/cgroup
0::/
这似乎是因为我的主机上启用了 cgroups v2（它曾经与 cgroups v1 一起使用）。
另一个答案建议检查该文件是否存在/.dockerenv。有用：
# test -e /.dockerenv && echo ok
ok
然而，Docker 维护者的评论（日期为 2016 年）建议不要依赖此文件（强调我的）：
最初，“.dockerenv”用于跨容器边界传输容器的环境变量——我也不建议依赖它的存在（IIRC，您链接到的代码是它仍然存在的唯一原因）。/sys/fs/cgroup 内可能有一些有罪的东西，但我最近没有检查过。
-- https://github.com/moby/moby/issues/18355#issuecomment-220484748
那么还有比这更好的方法吗？非常欢迎 Docker 维护者的回答。谢谢！
推荐指数
解决办法
查看次数
更改docker容器的swappiness
我正在使用docker来容纳大量服务.有时,集装箱化服务大量交换.我已经改变了vm.swappiness对1通过sysctl我的主机系统上.但是,docker的内存cgroup仍然具有旧的(默认)值60.因此,所有特定容器的cgroup具有与父级相同的值.
sysctl vm.swappiness
> vm.swappiness = 1
cat /sys/fs/cgroup/memory/docker/memory.swappiness
> 60
cat /sys/fs/cgroup/memory/docker/${CONTAINER_ID}/memory.swappiness
> 60
所有手动更改swappiness的尝试(通过将所需的值回显到memory.swappiness文件中)都失败了permission denied.
主题:如何限制容器swappiness？
我正在使用ubuntu 12.04内核3.13,我的docker版本是1.1.2本机执行驱动程序(不是lxc)的版本0.2.内核已加载cgroup_enable=memory swapaccount=1.
推荐指数
解决办法
查看次数
docker 容器中的防病毒 - fanotify 在主机和容器之间工作吗？
我需要使用开源软件对 docker 容器内的文件实施防病毒访问扫描解决方案。Clamav On-Access工作正常，但有一些要求和限制：
- 需要 CAP_SYS_ADMIN 功能才能在容器内工作
- 需要按容器运行，而不是按主机运行
- 每个正在运行的容器中的签名需要 850Mb 的驻留内存，即使是很小的一个
这个限制 - “从主机观看时，fanotify 不适用于容器事件”，真的存在还是我只是错误配置了 ClamAV？我对 fanotify 如何与命名空间一起工作没有深入的了解，但对我来说它看起来像是内核限制。
更新：是否有针对此限制的解决方法？添加/var/lib/docker/overlay2/container_id/merged是一种选择，因为动态容器性质clamd.conf需要在每个容器事件上更新。但即使添加了路径，ClamAV 也不会检测到容器中的恶意文件。
每个容器运行 ClamAV 会产生巨大的内存开销，尤其是对于小容器。
链接集合：
推荐指数
解决办法
查看次数
在 Debian 11 (Bullseye) 上，docker 容器内的 /proc/self/cgroup 不显示 docker 信息
我最近从 Debian 10 (Buster) 更新到 11 (Bullseye)，从那时起，我在 Docker 内的 Jenkins 设置就不再工作了，因为 Jenkins 试图通过检查/proc/self/cgroup.
通常，/proc/self/cgroupdocker 容器内部看起来像这样：
12:rdma:/
11:perf_event:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
10:freezer:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
9:memory:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
8:cpuset:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
7:devices:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
6:net_cls,net_prio:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
5:hugetlb:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
4:pids:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
3:cpu,cpuacct:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
2:blkio:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
1:name=systemd:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
0::/system.slice/containerd.service
但自从我更新到 Debian 11 后，它看起来很小：
0::/
由于 Jenkins 不再认识到它是在 docker 容器本身内运行，因此它会使用错误的参数启动其他构建容器。
问题
简单的问题是：这是一个错误吗？
但真正的问题可能是我做错了什么？我找不到其他人遇到此问题，因此可能是配置错误或类似的问题。
我重新安装了 Docker，删除了所有配置，甚至尝试将 Docker 降级到 20.10.6，因为这是我所知道的在 Debian 10 下运行的最后一个版本，但这些都没有改变任何东西。
我不知道如何进一步解决这个问题。我已经花了一整天的时间才发现问题不是 Jenkins 本身（几乎疯狂地阅读 Jenkins 日志）。我现在正在打基础，所以非常感谢任何帮助和意见！
詹金斯的东西
对于那些对 Jenkins 部分感兴趣的人，这里 Jenkins 检查它是否在容器内运行： https://github.com/jenkinsci/docker-workflow-plugin/blob/b174d46226ef1095903f2e789355a3b216b46dda/src/main/java/org/jenkinsci/plugins /docker/workflow/client/DockerClient.java#L347
Jenkins 认为它没有在容器内运行，会记录如下内容：
Jenkins does not seem to be running inside a container
$ …推荐指数
解决办法
查看次数
Kubernetes POD 是否有与其关联的命名空间和 cgroup？
Docker 容器具有与之关联的 cgroup 和命名空间，无论它们是在 pod、虚拟机还是主机中运行。
同样，Kubernetes Pod 是否具有与其关联的命名空间和 cgroup，或者只是 pod 内的容器具有这些（cgroup 和命名空间）关联。如果他们这样做，我如何从主机那里找到这些信息？
cgroups kubernetes docker-container linux-namespaces kubernetes-pod
推荐指数
解决办法
查看次数
标签 统计
cgroups ×10
docker ×6
linux ×6
kubernetes ×3
antivirus ×1
cadvisor ×1
clam ×1
containers ×1
cpu-usage ×1
debian ×1
go ×1
jenkins ×1
linux-kernel ×1
lxc ×1
memory ×1
performance ×1