【続】 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 キャッシュは、カーネルにメモリプレッシャ
Docker内部で利用されているLinuxカーネルの機能 (namespace/cgroups) - Qiita
Dockerで内部的に利用されているLinuxカーネルの機能について整理しています。 個人ブログの以下の2つのエントリーを1つにまとめたものになります。 Linuxカーネル Docker関連 namespaceのメモ Linuxカーネル Docker関連 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 namespace (名前空間) Linuxにおける namespace(名前空間) はプロセスに対して以下の6種類のリソースを分離するための機能として提供されています。 名前空間 定数 概要
LinuxにおけるOOM発生時の挙動 - Qiita
はじめに これはLinux Advent Calendar 2015 3日目の記事を2016/2/2に編集したものです。 Linuxにおいてシステムの物理メモリが枯渇したOut-Of-Memory(OOM)という状態になった際の挙動について説明しています。OOMに関連が深いsysctlパラメタを紹介するとともに、カーネルの内部論理についても触れました。 本記事に記載されているファイル名は、とくに断りが無ければカーネルソースのトップディレクトリからの相対パス名です。調査に使用したカーネルバージョンは4.3です。 本書は話を単純化するために、細かい動作論理については説明を省いていることをご承知おきください。また、本書の中に誤りを見つけたかた、および、私が追いきれなかったソースについての詳細をご存知のかたは、指摘していただけると助かります。 Out-Of-Memory(OOM)とOOM-kill
cgroup v2 の nsdelegate オプション（1）〜 namespace 外へのプロセス移動の禁止 - TenForward
cgroup v2がカーネルに導入された時点では、cgroup v2にはマウントオプションはありませんでした。 しかし、4.13 で nsdelegate というオプションが導入されました。これは現時点でも cgroup v2 唯一のマウントオプションです。 このオプションは初期の namespace でマウントするときにのみ指定できます。それ以外の namespace では無視されます。 cgroup namespace については、私の連載 の 第34回 で説明しました。ここでは、cgroup namespace で cgroup ツリーを独立させた後でも、cgroup namespace 内の /（root）を超えてプロセスを移動できました。 これはある意味コンテナ内のプロセスを、別のコンテナに移動させるという意味になります。 普通にコンテナを起動すると、mount namespac
cgroup v2 の nsdelegate オプション（2）〜 cgroup namespace 作成後の cgroup root を権限委譲の境界として扱う - TenForward
cgroup v2 の nsdelegate オプション第 2 弾です。 前回紹介したのは、cgroup namespace を作ると cgroup root を超えたプロセスの移動が禁止されるという機能でした。 これはユーザに関わらず関係するお話でしたが、今回は一般ユーザで namespace（つまりコンテナ）を作ったときのお話です。 私の連載の第 40 回 で紹介したとおり、cgroup v1 に比べて cgroup v2 は一般ユーザでプロセスを移動できる条件が厳しくなりました。ただ、これは実際のユースケースに合っている、というのは連載で書いたとおりです。 一般ユーザに cgroup ツリーを権限委譲する際には、権限委譲する root cgroup に当たる cgroup には、 ディレクトリへの書き込み権 cgroup ディレクトリ内の cgroup.procs ファイルへの書き込
LXC 3.0 新機能の予習 - TenForward
ここ最近、新バージョンリリース時と、ドキュメント（man pages）に更新があったときに翻訳する以外、新しい機能について全く調査していませんでした。 なんとなく見てると LXC 3.0 が近いようですので、どう変わるのかをまとめてみます。 cgroup ドライバの整理 これまで LXC には cgroup 関連のドライバが 3 つ含まれていました。 cgfs cgmanager cgfsng cgfs ドライバはもっとも古くからあるドライバです。今や cgroup は /sys/fs/cgroup にマウントされますが、昔は特にマウントする場所は決まっておらず、/dev/cgroup にマウントしたり、/cgroup にマウントしたりしていました。どこにマウントされるかわからないファイルシステムを検出するロジックなど、今や不要になったロジックが多く含まれています。 cgfs ドライバの機
cgroup: プロセスが所属しているmemoryサブシステムが使用しているメモリの使用量を見るツール - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
pythonでなんとなく。 show memory usage in memcg. memoryサブシステムにtest1を作ってメモリの上限を100Mで設定。 root@saga:/sys/fs/cgroup/memory/test1# cat memory.limit_in_bytes 104857600 root@saga:/sys/fs/cgroup/memory/test1# cat memory.memsw.limit_in_bytes 104857600 root@saga:/sys/fs/cgroup/memory/test1# pid 4473はtest1に所属するbashのプロセス。このシェルから1MiBのmalloc()を繰り返すプロセスを実行する。 ツールはpid 4473を指定して実行 masami@saga:~/codes/memcgstat$ ./memcgst
memory cgroupとpageのLRUめも - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
カーネルは4.1系です。 include/linux/mm_inline.hにLRUへの登録・削除処理の実装があります。 static __always_inline void add_page_to_lru_list(struct page *page, struct lruvec *lruvec, enum lru_list lru) { int nr_pages = hpage_nr_pages(page); mem_cgroup_update_lru_size(lruvec, lru, nr_pages); list_add(&page->lru, &lruvec->lists[lru]); __mod_zone_page_state(lruvec_zone(lruvec), NR_LRU_BASE + lru, nr_pages); } static __always_inlin
俺は Linux コンテナについてなんにも解っていなかった 〜 haconiwa で学ぶ Linux コンテナ (1) 〜 - ようへいの日々精進XP
追記 直近の Docker 界隈について Linux コンテナ 参考 Linux コンテナとは Linux コンテナを構成する主な機能 OS リソース毎の Namespace cgroup サブシステム こんなにざっくりでは、Linux コンテナは語れないと思うけど haconiwa haconiwa とは haconiwa で何が出来ると？ haconiwa 導入 はじめての haconiwa (1) はじめての haconiwa (2) 〜 コンテナ作成 〜 はじめての haconiwa (3) 〜 コンテナ起動 〜 haconiwa で学ぶ Linux コンテナ .haco ファイル再掲 namespace を弄る前に namespace uts namespace pid 俺は Linux コンテナについてなんにも解っていなかった(まとめ) haconiwa は Linux コンテ
cgroupのv1とv2の切り分け的なところ - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
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
コンテナー型仮想環境の情報交換会
コンテナー型仮想環境でシステムを構築を構築しようと考えている人は、カノジョが喜ぶことをするための時間を作るために、監視はDatadogでを使っちゃいましょうというはなし。 カノジョに取っては、プロメテウスも、ザビックスも、センスも、必要ない。彼氏が自分の嬉しいと思うことに時間を使ってくれるのが一番好き。Read less
PHPが動くApacheのコンテナ環境をhaconiwaで1万個動かそうとしてみた - 人間とウェブの未来
RubyKaigiに行くと本にサインを求められるすごいエンジニアが書いたhaconiwaというmruby製のコンテナエンジン（コンテナ環境構築の基盤ツール）があるのですが、少し試してみようと思って、とりあえず1サーバ上に1万コンテナぐらい動かそうとしてみました。久々に今回は自分の作ったOSSではなく、OSSの検証レポート的な記事になります。 haconiwaは僕の好きなOSSの一つで、それはなぜかと言うと、 haconiwaでコンテナを作る際に、haconiwa実行環境にはコンテナの要素機能が全て入っている必要はない 必要なコンテナの要素機能を簡単に組み合わせて、自分が実現したいコンテナ、あるいは、それに準ずる環境を作れる haconiwaによるコンテナ定義をRubyのDSLで表現でき、動的な設定や組み合わせの設定を簡単にかける ということができるからです。その特性から、CentOS6のよ
pid cgroupのコードを読む - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
この記事はLinuxカーネルもくもく会 #24 - connpassで書いてます。今日は前に追加されたcgroupsのpid管理のコードを読んでみます。 ファイルはcgroup_pids.cです。Linux 4.7のコードを対象にします。 最初にデータ構造です。pidの場合はpids_cgroup構造体が使われます。この構造体はcgroup_pids.cで定義されています。 43 struct pids_cgroup { 44 struct cgroup_subsys_state css; 45 46 /* 47 * Use 64-bit types so that we can safely represent "max" as 48 * %PIDS_MAX = (%PID_MAX_LIMIT + 1). 49 */ 50 atomic64_t counter; 51 int64_t l
systemdメモ - tom__bo’s Blog
Ubuntuで、キーボードの数字と記号を入れ替え（シフト無しで記号、シフトありで数字になる）ようにしようとしていた。 .profileで予め用意したキーマップをxmodmapコマンドで上書きしようとしたけど、Unityに上書きされるのか、上手く書き換えられなかったので、Systemdを使ってどうにかしようとした時のメモ。 結局途中でキーマップの変更方法は正しい方法が見つかったので、やっていない。 まずはsystemdの仕組みがわかっていなかったので、調べた内容から。 参考のURLを読めば仕組みは詳しく書いてあるので、まずはそれを読む。 特徴 高速なシステム起動と終了 高い並列度でプロセスを扱う 設定ファイルによるシステム管理の共通化 柔軟なプロセス起動 タイマーによる起動 socketへの通信検出によるプロセス起動 所定のパスへのファイル作成をトリガーとしたプロセス起動 cgroupsによ
Linuxのメモリダンプ解析の話 (その1) - Qiita
背景 社内で Linux マシンのとあるドライバの挙動がおかしいということで「ライブ crash で見たいなぁ」って呟いたら、「クラッシュって何？壊すの？」という反応が出て自分としてはカルチャーショックを受けたので、メモリダンプ解析の話を書いてみようと思いました。 色々と検索してみたところ、kdumpでメモリダンプ (世の中的にはクラッシュダンプと言う方が多い？) を採取する設定・手順についてはたくさんあるんですが、実際にその解析をどうやるのかって記事はあんまりないなぁと。パッと見つかったレベルだとこんな感じ。英文記事も探せば出てくるのだろうか。 VA Linuxの「ダンプ解析講座」の記事は結構ちゃんと書いてる。 O'Reillyの本 Debug Hacks -デバッグを極めるテクニック&ツール は結構ページ使って説明してる (役に立つかどうかは読み手次第)。 ミラクル・リナックスのLin
Linuxのメモリダンプ解析の話 (その2) - Qiita
Linuxのメモリダンプ解析の話 (その1) の続きです。 メモリダンプ解析の話に結構食いつきがあったので、引き続き書いてみたいと思います。カーネルの中身を理解するのは何故か敷居が高いと思われがちなのですが、全然そんなこと無いってことを分かっていただけると嬉しく思いますし、「ここが分かりにくい」みたいな話があれば教えていただけると有難いです。僕もまだまだカーネルの中身を知ってる段階ではなく、その都度調べてる状況なので。 個人的には Web 界隈の様々なミドルウェア・ツールが乱立してて理解が追いつきません。 それでは早速やりましょう。今回も Ubuntu 上での操作となります。 crashの操作 crash> log log コマンドはカーネル内のバッファに蓄積されたカーネルログを出力します。ログの中身は、一般的なシェル上から使うことのできる dmesg コマンドで出力されるものと同じはずで
cgroup なのか cgroups なのか - TenForward
割とどーでもいい話（でも気になってた人多いはずw） 以前、第4回のコンテナ勉強会でも質問が出たのですが、cgroup/cgroups という機能の正式な名称は cgroup なのか cgroups なのか、というのはよくわかりませんでした。 私は、英語って単数・複数をきちんと使い分けるし、cgroup は複数のサブシステム・コントローラが存在するので、海外の人は "cgroups" と複数形で使うんだろうなあと思ってました。機能自体を指しているのか、コントローラ群を含めて指しているのかって、曖昧な文脈も多いですし。 しかし、この論争にもついにピリオドが打たれました。カーネル付属文書の cgroup-v2.txt をご覧ください。 "cgroup" stands for "control group" and is never capitalized. The singular form i
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Curipha Networks
コンテナたちを計測すること ~ ロリポップ！マネージドクラウドの裏側 ~ /wip-how-to-get-container-metrics
cgroup v2 / 10th CTStudy
