タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
第37回で説明した通り、cgroup v1には様々な問題点が指摘されており、その問題を解決すべくcgroup v2が実装されました。 cgroup v1では、各コントローラがバラバラに実装されており、コントローラ間の連携が取れませんでした。これが原因で、リソースを制限するにあたって一番表面化していた問題が、ディスクI/Oに対して制限をかける際の問題でした。cgroup v1ではblkioコントローラでI/Oに対する制限をかけられましたが、限定的な制限しかかけられませんでした。 LinuxでのI/O コントローラ間で連携ができないため、blkioコントローラを使ったI/O制限が限定的になってしまう理由を説明するために、Linuxでディスクへファイル入出力する際の仕組みを簡単に説明しておきましょう。もう少し詳しい仕組みが知りたい方は『［試して理解］Linuxのしくみ』など、関連する書籍や文書を
Kubernetes で cgroup がどう利用されているか - VA Linux エンジニアブログ
はじめに 利用した環境 cgroup の階層構造 例：CPU やメモリの制限 例：PID 数の制限 例：CPU コアの排他的割り当て まとめ 執筆者 : 山下雅喜 はじめに cgroup とは、Linux カーネルの機能の1つであり、プロセスやスレッドが利用するリソースの制限や分離を行うための機能です。 cgroup は名前空間の機能と共に、Linux コンテナの根幹を成す技術の1つでもあります。 Kubernetes において、名前空間は PID 名前空間、ネットワーク名前空間、マウント名前空間などで利用者の目に触れやすい存在ではありますが、cgroup は相対的に目に付きにくいもののように感じています。 そこで今回は、Kubernetes のいくつかの機能を例に挙げ、cgroup がどう利用されているか見ていきます。 利用した環境 利用したソフトウェアおよびバージョンは次の通りです。
昨年12月に前回の記事を書いて以来、世の中の状況がすっかり変わってしまいました。 筆者も4月以降はほとんど会社に出勤することなく、自宅で仕事をしています。自宅の物置のように使っていたスペースを片付け、少しずついろいろなものを買い揃え、自宅でもまずまず快適な環境で仕事ができるようになりました。同様に、これを機に自宅でも快適に仕事ができるようにいろいろと買い揃えた方も多いのではないでしょうか。残念ながら、自宅の環境が快適になったからと言ってこの記事の公開ペースが速くなるということはありませんが。:-p さて、年末に書いた記事ではケーパビリティの話を3回に渡って説明しました。今回はそのケーパビリティシリーズの前に紹介していたcgroup v2の話題に戻って、その機能を紹介していきたいと思います。 cgroup v2とCPUコントローラ この連載の第37回で書いたように、cgroup v1は自由度
前回は、4.14カーネルでcgroup v2に導入されたスレッドモードの概要を説明しました。今回は、実際にスレッド化サブツリーを作成して操作を行ってみましょう。 今回の実行例は、デフォルトではcgroupをマウントしないPlamo Linux 7.2環境で試しています。systemdを採用したディストリビューションの場合、カーネルの起動パラメータにcgroup_no_v1=allと指定して、すべてのコントローラがcgroup v2から使えるようにするとcgroup v2の機能が試しやすいでしょう。 そして、今回の実行例はいずれもrootユーザで実行しています。 それでは早速、cgroup v2のツリー中でどのようにスレッド化サブツリーを作り、操作していくのかを見ていきましょう。 スレッド化サブツリーを作るには2つの方法があります。 cgroup.typeファイルへの書き込みによるスレッド化
前回は、CPUコントローラでの帯域幅制限がどのように行われるのかについて簡単に説明しました。 前回の最後に、説明のために挙げた例がかなり理想的な状況であると書きました。今回は、帯域幅制限の機能を詳しく見ていくために、前回よりはもう少し複雑な状況について説明していきましょう。 未使用クォータの返却 前回説明で示した例では、CPUは割り当てられたスライスをすべて使いきっていました。しかし、複数のCPUがある環境で、タスクが終了したり、I/O待ちなどにより、クォータが割り当たったCPUで実行可能なタスクがなくなった場合はどうなるでしょう? 図1 割り当てられたスライスが使われない場合 図1のように、クォータプールに10msクォータが残っているとします。 ①でCPU1でCPUを使用するタスクから要求がありスライスが転送され、クォータの残りが5msとなりました ②で再度CPU1でCPUを使用するタス
【続】 Linux Kernel: cgroup 削除後も残り続ける slab キャッシュ についての調べ物 - upsteam は修正パッチが入って解決済み - hibomaの日記
以前に下記のエントリを書きました。勉強会に登壇するネタとして調べ直したところ 新しい 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 キャッシュは、カーネルにメモリプレッシャ
第12回 コンテナ技術の情報交換会@オンラインにて 「cgroup と sysfs ファイル - トラブルシューティングから cgroup を深追いする」を発表しました - hibomaの日記
第12回 コンテナ技術の情報交換会@オンラインに発表しました! ct-study.connpass.com スライド 発表のスライドは下記で公開しております speakerdeck.com speakerdeck でフォントがしゃばしゃばになるのを解決できていないので、PDF でも公開しています ... github.com スライドの概要 弊社 GMO ペパボの ロリポップ！マネージドクラウドでのトラブルシューティング事例を契機として cgroup の sysfs ( スラブキャッシュ ) 周りを追いかけた内容を発表しています。 発表内容は、過去のエントリを勉強会向けにまとめ直した内容です。モデル図などを加筆しています。 hiboma.hatenadiary.jp トラブルの詳細については、ブログでは過去にも公開していなかった内容で、今回の発表でのみ閲覧できます。当時、実際に記録したコマ
Linux Kernel: cgroup 削除後も残り続ける slab キャッシュ についての調べ物 - hibomaの日記
タイトルの通りで、コンテナの生成と削除が頻繁におこなわれているホストで、 cgroup 削除後も特定の slab キャッシュ ( + sysfs のファイル = kobject ) が残るという現象を調べていました 環境 vagrant@bionic:~$ uname -a Linux bionic 5.4.1-050401-generic #201911290555 SMP Fri Nov 29 11:03:47 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux 再現の方法 cgroup v1 + memory コントローラーでグループを作る そのグループ内で適当なファイルを作成する cgroup のグループを削除する とすれば ok です #!/bin/bash set -ex for i in {1..10}; do mkdir /sys/fs/cgro
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
Linux Daily Topics 2020年4月7日Linux 5.7の新機能 ―親プロセスとは異なるcgroupへのプロセス生成が可能に 3月29日（米国時間）に「Linux 5.6」がリリースされ、現在は次期Linuxカーネル「Linux 5.7」のマージウインドウがオープン中だが、その大きなアップデートのひとつとして、プロセスを生成する際、親プロセスとは異なるコントロールグループ（cgroup）下に直接、プロセスを生成する機能がマージされることがほぼ確実となった。 [GIT PULL] cgroup changes for v5.7-rc1 Commits -torvalds /linux -GitHub この機能はプロセス/スレッドを生成するシステムコール「clone3」を拡張したもので、カーネルメンテナーのChristian Braunerがメインで作業にあたっている。実装さ
とある python ライブラリが mmap(2) を使ってファイルを MAP_SHARED | MAP_POPULATE flags 付きでメモリに読み込んでいたので、その時 Linux メモリ管理系ツールではどういう挙動になるかチラ裏。 mmap お試しコード #include <fcntl.h> #include <stdlib.h> #include <sys/mman.h> #include <sys/stat.h> #include <unistd.h> #include <stdio.h> int main() { int fd = open("abc.txt", O_RDONLY, (int)0400); off_t size = lseek(fd, 0, SEEK_END); printf("start\n"); char* addr = mmap(NULL, size,
前回は、cgroup v2から使うioコントローラの話題を取り上げました。今回も前回に引き続きioコントローラについて書こうかと思ったのですが、cgroup v2のioコントローラが持つ機能は想像以上に難解で、記事を書けるほどの理解が得られていないので、今回はcgroup v2から使うCPUコントローラの話をしたいと思います[1]。 この連載でCPUコントローラについて書いたのは、2014年に書いた第4回でした。このときはまだcgroup v2はありませんでしたので、cgroup v1[2]を使った説明でした。 このあと、cgroup v2が実装され、cgroup v2でしか使えない機能が多数実装されています。前回紹介したioコントローラとメモリコントローラの連携もそうです。 しかし、実はCPUコントローラはcgroup v1とv2で機能にはほぼ差がありません。cgroup v2がstab
はじめに Kubernetes は v1.25 で cgroup v2 サポートを GA しており、その後に cgroup v2 に関連する機能が追加されています。しかしまだ多くのディストリビューションで Kubernetes がデフォルトで cgroup v2 を使用しない設定のため、実際に利用している方は多くないと思います。PFN では2022年12月に Kubernetes バージョンを v1.25 にアップグレードするのと同じタイミングで cgroup v2 に切り替えています。 このエントリでは Kubernetes の cgroup v2 に関する機能である MemoryQoS フィーチャゲートと memory.oom.group の2つについて、機能概要と課題を共有します。なお、Kubernetes v1.28 時点での情報です。 そもそもの cgroup v2 について そ
5.13カーネルを使っており、デフォルトでcgroup v2のみがマウントされているUbuntu 21.10の環境では、root cgroup配下のcgroup.controllersは次のようになっています。 $ uname -r 5.13.0-21-generic $ grep cgroup /proc/self/mountinfo 35 25 0:30 / /sys/fs/cgroup rw,nosuid,nodev,noexec,relatime shared:9 - cgroup2 cgroup2 rw,nsdelegate,memory_recursiveprot $ cat /sys/fs/cgroup/cgroup.controllers cpuset cpu io memory hugetlb pids rdma misc Ubuntu 21.10のような新しい環境では、
メモ程度に。 追記 @ 2021/04/20 12:41 inode番号と同じになるようになっているらしい。なので、 cgpath = ARGV[0] puts File::Stat.new(cgpath).ino これだけでいいです... 以下は、構造体キャストの例として残す。 github.com この実装によると name_to_handle_at をつかってcgroupを表すディレクトリ のファイルハンドルを取る ファイルハンドルを以下の構造体にキャストする struct cgid_file_handle { unsigned int handle_bytes; int handle_type; uint64_t cgid; }; そうすると handle->cgid に入ってる という感じっぽい。なので言語を選ばず実装できる。Rubyのようなスクリプト言語ならffi（fiddle
Dockerコンテナの仕組み -namespace、cgroup、overlayfs- ここまでDockerを使ったコンテナの操作について説明してきました。今回はコンテナの要素技術について解説していきます。 Dockerコンテナの特徴には次のようなものがあります。 コンテナのシステムリソースの隔離 ファイルのレイヤ構造 コンテナ間の通信 Dockerコンテナでは上記機能を実現するためにいくつかのLinuxが持つ機能を利用しております。主要なものとして以下の3つがよく挙げられます。 overlayfs namespaces cgroups ここらからコンテナの3つの特徴を実現するための要素技術について見ていきたいと思います。 コンテナのシステムリソースの隔離機能 コンテナはOSカーネルが持っている環境を隔離する機能を使っています。コンテナごとに、1つの仮想マシンのように独立した環境を持つこと
前回はcgroup v2で使えるコントローラのうち、v1から大きく変わったコントローラや、新たに実装されたコントローラについて説明しました。 今回はcgroup v2で行われるリソース制御のタイプ、cgroupで使うインターフェースファイルに関係する規則や、コントローラでリソース制限を設定する際に関係するファイルのフォーマットや書き込み方について説明したいと思います。 cgroupとcgroup内ファイルの命名規則 cgroup v1には、cgroupで使用するファイルやその内部の書式について、明確な規則はありませんでした。cgroup v2では、ファイルに関する規則がきちっと定められました。この決まりを説明していきましょう。 今回の実行例は、前回と同じくUbuntu 21.10環境で実行しています。 まず、cgroup自体の動きに影響するcgroupコアに関係するインターフェースファイル
本記事は、TechFeed Experts Night#19 〜 達人に聞く、Linuxカーネルコードの歩き方のセッション書き起こし記事になります。 イベントページのタイムテーブルから、その他のセッションに関する記事もお読み頂けますので、一度アクセスしてみてください。 本セッションの登壇者 セッション動画 それでは「cgroupの歩き方」ということで、実際にコードを読むときのお話をしたいと思います。 まずは自己紹介です。加藤と申します。SNSは@ten_forwardという名前でやっていることが多いです(Twitter)。gihyo.jpでコンテナの連載を2014年からずっとやっております。コンテナは完全に趣味でやっていて、仕事の方はIDCフロンティアという会社でセキュリティの仕事をしています。
Linux Kernel: cgroup, sysfs, kobject, uevent についての調べ物 - hibomaの日記
cgroup v1 + memory コントローラーで制限を課した際に、sysfs のファイル = kboject が生成/削除されるタイミングやその仕組みを調べていました 例えば下記のような sysfs のファイルです /sys/kernel/slab/dentry/cgroup/dentry(979:@hogehoge)/objects /sys/kernel/slab/kmalloc-4k/cgroup/kmalloc-4k(979:@hogehoge)/objects /sys/kernel/slab/kmalloc-32/cgroup/kmalloc-32(979:@hogehoge)/objects /sys/kernel/slab/kmalloc-2k/cgroup/kmalloc-2k(979:@hogehoge)/objects /sys/kernel/slab/kmal
Five Things to Prepare for Cgroup v2 with Kubernetes - Kintone Engineering Blog
By Daichi Sakaue (@yokaze) Above all the effort of the community, Kubernetes is now ready to run with cgroup v2. We recently migrated our on-premises Kubernetes clusters to use cgroup v2 and discovered some key points to know. This blog post explains what cgroup v2 is, what it brings to Kubernetes, and how to prepare for it. TL;DR Configure kubelet and the container runtime in use to use the syste
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
「第13回コンテナ技術の情報交換会＠オンライン」の発表資料です。 参考となる情報にはPDF中からリンクをしていますが、資料中のリンクは Speaker Deck 上ではクリックできないので PDF をダウンロードしてご覧ください。
元ネタ : https://twitter.com/_fel1x/status/1151487051986087936 d=`dirname $(ls -x /s*/fs/c*/*/r* |head -n1)` mkdir -p $d/w;echo 1 >$d/w/notify_on_release t=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab` touch /o; echo $t/c >$d/release_agent;echo "#!/bin/sh $1 >$t/o" >/c;chmod +x /c;sh -c "echo 0 >$d/w/cgroup.procs";sleep 1;cat /o — Felix Wilhelm (@_fel1x) July 17, 2019 特権( CAP_SYS_ADMIN )コンテナで cgr
eBPF Updates #2: eBPF with Zig, libbpf-bootstrap, Rust Linker, BTF in Kernel Modules, Cgroup-Based Memory Accounting Foreword Welcome to the second issue of the eBPF Updates! This time we have interesting resources about how to write eBPF programs with Zig, or with Rust, or on how to manage them with libbpf. On the kernel side, modules now support BTF, and improvements to memory accounting for eBP
taskset と cgroup は何が違うのか
taskset と cgroupは、あるプロセスが利用可能な CPU コアを制限できる技術。どんな違いがあるのかを調べた。なお、本記事の cgroup は cgroup v1 のこと。 taskset は sched_setaffinity システムコールを利用したコマンドラインツール。sched_setaffinity はユーザが実行したプロセスの CPU Affinity をユーザの権限で変えられる。プロセスからは CPU が存在するけど自発的に使わない状態。(≒このコアじゃないとヤダ！)cgroup は CPU/メモリなどのリソースを隔離するための仕組み。cgroup は設定権限をファイルのパーミッションで管理し、ユーザからの操作を禁止できる。プロセスからは CPU が存在しない状態。(≒このコアだけ使ってね)sched_setaffinity と cgroup はユーザへのインタフ
Kubernetes: cgroup v2 使用時に "failed to create fsnotify watcher: too many open files" エラーが発生する問題の対策 - Qiita
Kubernetes: cgroup v2 使用時に "failed to create fsnotify watcher: too many open files" エラーが発生する問題の対策cgroupskubernetescontainerdcgroup-v2 はじめに Kubernetes 1.25 で cgroup v2 が GA しました。Kubernetes で cgroup v2 に移行するとメモリ QoS が導入され、Pod のメモリ使用量が増加した際の安定性が向上するメリットがあります1。そこでクラスタを Kubernetes 1.25 にアップグレードする際に一緒に cgroup v2 に移行したのですが、移行後に kubectl logs -f コマンドやノードのホスト上で journalctl -f を実行した際に次のエラーが発生するようになりました。
cgroup の CPU コントローラーから設定する帯域幅制限のコードをちょっとだけ追ってみた - TenForward
この記事は Linux Advent Calendar 2023 5 日目の記事です。前日は @mnishiguchi さんの「Linux US キーボードの CapsLock を Ctrl に変更する方法」ですね。私は setxkbmap でやってます。 さて、このブログ久々の技術的な内容です。Linux カーネルが持つ cgroup という機能のうち、タスクやタスクのグループに対して CPU の帯域制限（単位時間内にどれだけ CPU が使えるか）を設定できる機能のコードを少し追ってみたお話です。あとで紹介する gihyo.jp さんに掲載している記事とあわせて読んでいただけるとよりうれしいです。 もう 4 年くらいまえのブログなんですが、Indeed さんのエンジニアリングブログのこの 2 つの記事がすばらしいんです。わかりやすい。もう cgroup の CPU コントローラーから使う
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
第52回 Linuxカーネルのコンテナ機能 ― cgroupを使ったI/O制限 | gihyo.jp
第45回 Linuxカーネルのコンテナ機能 ― cgroupの改良版cgroup v2［6］ | gihyo.jp
第46回 Linuxカーネルのコンテナ機能 ― cgroupの改良版cgroup v2［7］ | gihyo.jp
第54回 Linuxカーネルのコンテナ機能 ―cgroup v2から使うCPUの帯域幅制限（2） | gihyo.jp
The current adoption status of cgroup v2 in containers
2020年4月7日 Linux 5.7の新機能 ―親プロセスとは異なるcgroupへのプロセス生成が可能に | gihyo.jp
mmap と free と ps と cgroup - Qiita
第53回 Linuxカーネルのコンテナ機能 - cgroup v2から使うCPUの帯域幅制限（1） | gihyo.jp
Kubernetes と cgroup v2 - Qiita
第48回 cgroup v2から使うコントローラとmiscコントローラ | gihyo.jp
eBPF的な意味で使えるcgroup idを取る方法 - ローファイ日記
Dockerコンテナの仕組み -namespace、cgroup、overlayfs-
第49回 cgroup v2のリソース分配の方法とインターフェースファイルの操作 | gihyo.jp
cgroupの歩き方 ‐ 初期化/コア/コントローラを少しずつ追いかける
cgroup v2の、BPFによるデバイスアクセス制御を試す - ローファイ日記
cgroup v1 の内部構造 / 13th CTStudy
cgroup の release_agent を使った特権コンテナからのエスケープ
eBPF Updates #2: eBPF with Zig, libbpf-bootstrap, Rust Linker, BTF in Kernel Modules, Cgroup-Based Memory Accounting
note.com/goto_finance
note.com/choumiryou
machabon.hatenablog.com
gumi-create.hatenablog.com
news.infoseek.co.jp
ameblo.jp/winningticket-2025