RubyKaigiも近付いたしeBPFの機運を高めようとしている。 タイトルですが、そういうことができます。 www.kernel.org このドキュメントにも「どうすればできる」と言うところが書いておらず、最終的にカーネルのサンプルを眺めることになる。 elixir.bootlin.com elixir.bootlin.com 下準備 まず、cgroup v2が有効なカーネルを使う必要がある。いったん。Ubuntu Groovy（5.8.0-53-generic）を使う。 その上で、cgroup v1のdevicesコントローラを一応umountしておいいた。必要なのかはわからないが...。 $ sudo umount -l /sys/fs/cgroup/devices その上で cgroup v2のグループを作成。 $ sudo mkdir /sys/fs/cgroup/unified
はじめに 利用した環境 cgroup の階層構造 例：CPU やメモリの制限 例：PID 数の制限 例：CPU コアの排他的割り当て まとめ 執筆者 : 山下雅喜 はじめに cgroup とは、Linux カーネルの機能の1つであり、プロセスやスレッドが利用するリソースの制限や分離を行うための機能です。 cgroup は名前空間の機能と共に、Linux コンテナの根幹を成す技術の1つでもあります。 Kubernetes において、名前空間は PID 名前空間、ネットワーク名前空間、マウント名前空間などで利用者の目に触れやすい存在ではありますが、cgroup は相対的に目に付きにくいもののように感じています。 そこで今回は、Kubernetes のいくつかの機能を例に挙げ、cgroup がどう利用されているか見ていきます。 利用した環境 利用したソフトウェアおよびバージョンは次の通りです。
以前に下記のエントリを書きました。勉強会に登壇するネタとして調べ直したところ 新しい Linux カーネルでは問題が解決されていました。 hiboma.hatenadiary.jp hiboma.hatenadiary.jp hiboma.hatenadiary.jp hiboma.hatenadiary.jp どんな問題ですか? 「cgroup を削除した後も sysfs の slab キャッシュ が残る」 と 「slab キャッシュ が reclaim されるタイミングで必要のない uevent が送出される」 という二つの問題でした。 問題 と書いていますが、対象の slab キャッシュは inode っキャッシュや dentry キャッシュ であり、reclaimable な slab キャッシュです。 reclaimable な slab キャッシュは、カーネルにメモリプレッシャ
Fedora 31 was released on October 29, 2019. This is the first major distro that comes with cgroup v2 (aka unified hierarchy) enabled by default, 5 years after it first appeared in Linux kernel 3.16 (Aug 3, 2014). While the adoption of cgroup v2 is an inevitable step toward 2020s, most container implementations including Docker/Moby and Kubernetes still don’t support cgroup v2. If you attempt to in
ComSys 2018でしゃべったスライドです。音声なしでは非常に不親切なスライドかとは思いますが公開しないのも違うかなと言うことで公開します。
Ubuntuの次の長期サポート版のリリースが近づいています。それに合わせて、LXC関連のプロダクトもメジャーバージョンアップし、新しい長期サポート版をリリースしました。筆者はlinuxcontainers.orgやLXC/LXD関連の翻訳をやっていますので、一気に翻訳対象が増えて大変です。一度には出来ないので毎日少しずつ進めています。 さて、前回は、cgroup v2で使うファイルや、基本操作、親cgroupから子cgroupで使うコントローラを指定する方法を紹介しました。 今回も引き続き、cgroup v2が持つ基本的な機能を紹介していきましょう。 まずは、cgroup v2の特徴のひとつである、プロセスが末端のcgroupにしか所属できないことを紹介します。そのあと、cgroupが持つ状態通知機能について紹介します。この機能については、これまで連載で紹介していなかったv1の機能を含めて
前回の記事は、私が所属する会社のAdvent Calendarの5日目の記事でした。これまでは、この連載記事でAdvent Calendarに参加するのは1回だけでした。 今年はcgroup v2の話題を書こうと決めたときに、内容から考えて1回では済まない量になるだろうと思いました。そこで、続けて2回でcgroup v2の紹介をして、2つのAdvent Calendarに参加しようと決めました。1回目はちょうど社内で募集が始まっていた会社のAdvent Calendar、2回目は例年どおりLinux Advent Calendarに参加することにしました。 そういうわけで、今回の記事は昨年まで何度か参加していたLinux Advent Calendar 2017の19日目の記事です。 今回は、実際にcgroup v2を操作しながら、前回紹介したcgroup v2の特徴をおさらいしましょう。
この連載をはじめてから、毎年この連載の記事でAdvent Calendarに参加してきました。昨年までは、この連載の記事で"Linux Advent Calendar"に参加してきました。 今年は参加するカレンダーを少し変えて、まずはこの記事で私が所属する会社のAdvent Calendarであるファーストサーバ Advent Calendar 2017の5日目に参加してみます。あまりたくさんの人が興味を持たなさそうな話題なので、会社のAdvent Calendarにマッチするのか心配です (^_^;)。 さて、Linuxでコンテナでリソース制限を行うための機能として、この連載では第3回から第5回まで3回に渡ってcgroupについて解説しました。 cgroupは、多くのLinuxディストリビューションでinitとして採用されているsystemdが使っていますので、今やLinuxをお使いであ
cgroupはv1とv2という2つの実装（と言っていいのか？）があってそれらはkernel/cgroup.cで一つのコードベースにまとまっているのでコード読んでで混乱するなーというところで、誰得なめもを。 特に、4.1とかのカーネルだとv2のコードはまだ正式版となってないけどマージはされていて、DEVELsane_behaviorというオプションを使うことでv2の機能が使えるようになってます（参考： Linux 3.16 から試せる cgroup の単一階層構造 (1) - TenForward）。今はv2がちゃんと入っているのでこのオプションは不要で、cgroupのマウント時にcgroup v2としてマウントするかどうかで切り分けできます。cgroup_mount()のis_v2がそれです。 2083 static struct dentry *cgroup_mount(struct f
さて、今年もAdvent Calendarの季節になりました。例年通り今年もいろいろなカレンダーがあって盛り上がっていますね。筆者もいくつかエントリしたので、そのための記事を書くのが大変です。 そのエントリしたカレンダーのひとつがLinux Advent Calendar 2016です。一昨年から、この連載の記事をLinux Advent Calendar 2015、2014へのエントリと兼ねて書いてきました。 今年も同様に、この記事をLinux Advent Calendar 2016 13日目の記事として書きました。Linux Advent Calendar 2016には今年もマニアックで面白いエントリが並んでいますね。 昨年のエントリ（第30回）は、Linuxカーネルに新たに追加されたcgroupのpidsサブシステムを紹介しました。今年は、Linuxカーネルが持つコンテナ関連機能と
Long-running technical disagreements are certainly well-known in the kernel community. Usually they are eventually resolved and the developers involved move on to new problems. Occasionally, though, stalled consensus can lead to a break between the kernel and its user community. The ongoing dispute over the CPU controller in the new control-group hierarchy is beginning to look like one of those un
前回はLinuxの namespace(名前空間) についてCプログラムやツールを使っていろいろと確認できましたので、今回は cgroups についても調べます。 Linuxカーネル Docker関連 namespaceのメモ namespaceは生成したプロセスに対してリソース体系を割り当てる(隔離空間を作る)のに対して、cgroupsは指定したプロセスのグループに対してリソース制限をかけます。似ているようで全然別の機能ですね。 環境 * CentOS 7.2 (kernel-3.10.0-327.4.5.el7.x86_64) * Ubuntu 14.04 (3.13.0-77-generic) * Docker 1.9.1 cgroups Control Groups provide a mechanism for aggregating/partitioning sets of t
割とどーでもいい話（でも気になってた人多いはずw） 以前、第4回のコンテナ勉強会でも質問が出たのですが、cgroup/cgroups という機能の正式な名称は cgroup なのか cgroups なのか、というのはよくわかりませんでした。 私は、英語って単数・複数をきちんと使い分けるし、cgroup は複数のサブシステム・コントローラが存在するので、海外の人は "cgroups" と複数形で使うんだろうなあと思ってました。機能自体を指しているのか、コントローラ群を含めて指しているのかって、曖昧な文脈も多いですし。 しかし、この論争にもついにピリオドが打たれました。カーネル付属文書の cgroup-v2.txt をご覧ください。 "cgroup" stands for "control group" and is never capitalized. The singular form i
Control Group v2 以前も少し紹介していましたし、連載でも少し触れましたが、今広く (?) 使われている cgroup は色々問題があって、単一階層構造の cgroup が開発されていました。この辺りは Linux 3.16 から試せる cgroup の単一階層構造 (1) - TenForwardの日記 Linux 3.16 から試せる cgroup の単一階層構造 (2) - TenForwardの日記 で紹介しました。 以前は開発中の機能だったため、マウントするときに "__DEVEL__sane_behavior" などというふざけたオプションが必要でした。(^^) この後も順調に (?) 開発はすすみ、4.5 カーネルのリリースでついにこの機能が stable となったようで、"__DEVEL__" というプレフィックスも不要になりましたし、正式な機能で「まともなふ
CPUやメモリ、IOといったリソースの制限下でとあるコマンドを実行させたい場合に、cgroup上に何かgroupを作ったりしてからcgexecを実行して、実行後はそのgroupを消す、といったような一手間かかる方法がほとんどでした。 実行後のgroupも綺麗にしたい、といった所まで考えるとなかなか手間がかかっていたので、それらを全てワンラインでできるrconというワンバイナリで動くツールを作りました。 github.com 例えば、負荷サーバでの調査ツールを流す際に、CPUとかIOとかを制限しつつドロドロ実行したい場合等に便利です。Linuxのcgroup対応した環境でのみ動きます。 使い方 ほぼREADME通りなのですが、オプションは代替以下のようになっています。 --memは変なので--memoryに変更しました!! ./rcon --help Usage: rcon [options
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く