cgroup

Mon服务检查 查看对应进程是否在cgroup策略里面 OSD服务检查 来源： oschina 链接： https://my.oschina.net/u/97044/blog/402341

重启cgroup服务 service cgconfig restart 重启mon和osd服务 service ceph-mon-all restart service ceph-osd-all restart 来源： oschina 链接： https://my.oschina.net/u/97044/blog/402340

节点cpu和内存节点查看 准备配置文件 编辑/etc/cgconfig.conf 注意mon和osd部分根据实际情况进行增加 以下为配置文件 mount { cpu = /sys/fs/cgroup/cpu; cpuacct = /sys/fs/cgroup/cpuacct; cpuset = /sys/fs/cgroup/cpu; devices = /sys/fs/cgroup/devices; memory = /sys/fs/cgroup/memory; freezer = /sys/fs/cgroup/freezer; } group mon { perm { task { uid = root; gid = root; } admin { uid = root; gid = root; } } cpu { cpuset.cpus = 0; cpuset.mems = 0; } memory { memory.limit_in_bytes = 2g; memory.memsw.limit_in_bytes = 3g; memory.soft_limit_in_bytes = 1g; memory.swappiness = 0; memory.oom_control = 1; memory.failcnt = 1; } } group osd0 { perm { task

一、 Cgroup介绍 Cgroup是什么 Cgroups是control groups的缩写，是Linux内核提供的一种可以限制、记录、隔离进程组（process groups）所使用的物理资源（如：cpu,memory,IO等等）的机制。最初由google的工程师提出，后来被整合进Linux内核。Cgroups也是LXC为实现虚拟化所使用的资源管理手段，可以说没有cgroups就没有LXC。 Cgroup能做什么 Cgroups最初的目标是为资源管理提供的一个统一的框架，既整合现有的cpuset等子系统，也为未来开发新的子系统提供接口。现在的cgroups适用于多种应用场景，从单个进程的资源控制，到实现操作系统层次的虚拟化（OS Level Virtualization）。Cgroups提供了一下功能： 限制进程组可以使用的资源数量（Resource limiting ）。比如：memory子系统可以为进程组设定一个memory使用上限，一旦进程组使用的内存达到限额再申请内存，就会出发OOM（out of memory）。 进程组的优先级控制（Prioritization ）。比如：可以使用cpu子系统为某个进程组分配特定cpu share。 记录进程组使用的资源数量（Accounting ）。比如：可以使用cpuacct子系统记录某个进程组使用的cpu时间 进程组隔离

这是 Cgroup 系列的第四篇，往期回顾： Linux Cgroup 入门教程：基本概念 Linux Cgroup 入门教程：CPU Linux Cgroup 入门教程：内存 通过 上篇文章 的学习，我们学会了如何查看当前 cgroup 的信息，如何通过操作 /sys/fs/cgroup 目录来动态设置 cgroup，也学会了如何设置 CPU shares 和 CPU quota 来控制 slice 内部以及不同 slice 之间的 CPU 使用时间。本文将继续探讨对 CPU 使用时间的限制。 对于某些 CPU 密集型的程序来说，不仅需要获取更多的 CPU 使用时间，还要减少工作负载在节流时引起的上下文切换。现在的多核系统中每个核心都有自己的缓存，如果频繁的调度进程在不同的核心上执行势必会带来缓存失效等开销。那么有没有方法针对 CPU 核心进行隔离呢？准确地说是把运行的进程绑定到指定的核心上运行。虽然对于操作系统来说，所有程序生而平等， 但有些程序比其他程序更平等。 对于那些更平等的程序来说，我们需要为它分配更多的 CPU 资源，毕竟人都是很偏心的。废话少说，我们来看看如何使用 cgroup 限制进程使用指定的 CPU 核心。 1. 查看 CPU 配置 CPU 核心的编号一般是从 0 开始的，4 个核心的编号范围是 0-3 。我们可以通过查看 /proc/cpuinfo

We want to use systemd as cgroup driver for docker and kubelet, let's see how to achieve that. Configure docker After you install and start docker, by default it will use cgroupfs as the cgroup driver, check by running: docker info | grep Cgroup Cgroup Driver: cgroupfs Edit /usr/lib/systemd/system/docker.service file: ExecStart=/usr/bin/dockerd --exec-opt native.cgroupdriver=systemd Then reload daemon and restart docker systemctl daemon-reload systemctl restart docker Verify the change docker info | grep Cgroup Cgroup Driver: systemd Configure kubelet Currently, the kubelet cannot

本文仅是对kernel中的document进行翻译，便于理解。后续再添加代码分析。 1. 为何引入schedtune？ schedutil是一个基于利用率驱动的cpu频率governor。它允许调度器为了cpu上运行的task选出最优的工作频率点（DVFS operating point: OPP）。 但是，有时候我们需要故意进行boost，来满足特定场景下的性能要求，尽管这样会产生更大的功耗。比如，为了缩短task的响应时间，我们希望task运行在一个比实际cpu带宽要求更高的OPP。 还有一个重要原因是我们想用schedutil governor来替代当前所有的CPUFreq pollicy。schedutil是基于event的，而当前governor是基于采样的，所以schedutil对task选择最优OPP的更加迅速。但是仅仅跟踪实际的task使用率可能不足以表达当前的性能。比如，它不能做到类似“performance”、“interactive” CPUFreq governor的相关行为。 于是，就引入了schedtune。它是一套处于governor架构上层的、可调节的工具，扩展了对task performance boosting的支持。 performance boosting的意思：缩短task启动的时间。例如，一个task从唤醒到其再次休眠或者退出的时间

深入解析 Linux 容器 今天的内容主要分成以下三个部分 资源隔离和限制； 容器镜像的构成； 容器引擎的构成； 前两个部分就是资源隔离和限制还有容器镜像的构成，第三部分会以一个业界比较成熟的容器引擎为例去讲解一下容器引擎的构成。 容器 容器是一种轻量级的虚拟化技术，因为它跟虚拟机比起来，它少了一层 hypervisor 层。先看一下下面这张图，这张图简单描述了一个容器的启动过程。 最下面是一个磁盘，容器的镜像是存储在磁盘上面的。上层是一个容器引擎，容器引擎可以是 docker，也可以是其它的容器引擎。引擎向下发一个请求，比如说创建容器，然后这时候它就把磁盘上面的容器镜像，运行成在宿主机上的一个进程。 对于容器来说，最重要的是怎么保证这个进程所用到的资源是被隔离和被限制住的，在 Linux 内核上面是由 cgroup 和 namespace 这两个技术来保证的。接下来以 docker 为例，来详细介绍一下资源隔离和容器镜像这两部分内容。 一、资源隔离和限制 namespace namespace 是用来做资源隔离的，在 Linux 内核上有七种 namespace，docker 中用到了前六种。第七种 cgroup namespace 在 docker 本身并没有用到，但是在 runC 实现中实现了 cgroup namespace。 我们先从头看一下： 第一个是 mount

原文地址： https://www.yangcs.net/posts/understanding-resource-limits-in-kubernetes-cpu-time/ 在关于 Kubernetes 资源限制的系列文章的 第一篇文章 中，我讨论了如何使用 ResourceRequirements 对象来设置 Pod 中容器的内存资源限制，以及如何通过容器运行时和 linux control group（ cgroup ）来实现这些限制。我还谈到了 Requests 和 Limits 之间的区别，其中 Requests 用于在调度时通知调度器 Pod 需要多少资源才能调度，而 Limits 用来告诉 Linux 内核什么时候你的进程可以为了清理空间而被杀死。在这篇文章中，我会继续仔细分析 CPU 资源限制。想要理解这篇文章所说的内容，不一定要先阅读上一篇文章，但我建议那些工程师和集群管理员最好还是先阅读完第一篇，以便全面掌控你的集群。 1. CPU 限制 正如我在上一篇文章中提到的， CPU 资源限制比内存资源限制更复杂，原因将在下文详述。幸运的是 CPU 资源限制和内存资源限制一样都是由 cgroup 控制的，上文中提到的思路和工具在这里同样适用，我们只需要关注他们的不同点就行了。首先，让我们将 CPU 资源限制添加到之前示例中的 yaml： resources:

持续集成 创建jenkins目录及Dockerfile $ mkdir jenkins && cd jenkins $ touch Dockerfile $ vim Dockerfile # Version 0.0.1 FROM ubuntu:14.04 MAINTAINER Hadeian RUN apt-get update && apt-get install -y curl apt-transport-https software-properties-common RUN apt-key adv --keyserver keyserver.ubuntu.com --recv-keys F76221572C52609D RUN echo "deb https://apt.dockerproject.org/repo ubuntu-trusty main" > /etc/apt/sources.list.d/docker.list RUN add-apt-repository ppa:openjdk-r/ppa RUN apt-get update && apt-get install -y iptables ca-certificates openjdk-8-jdk git-core docker-engine ENV JENKINS_HOME /opt/jenkins