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: プロセスが所属している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
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
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
4.5 カーネルで stable となった cgroup の単一階層構造 cgroup v2 の io コントローラ - TenForward
Control Group v2 以前も少し紹介していましたし、連載でも少し触れましたが、今広く (?) 使われている cgroup は色々問題があって、単一階層構造の cgroup が開発されていました。この辺りは Linux 3.16 から試せる cgroup の単一階層構造 (1) - TenForwardの日記 Linux 3.16 から試せる cgroup の単一階層構造 (2) - TenForwardの日記 で紹介しました。 以前は開発中の機能だったため、マウントするときに "__DEVEL__sane_behavior" などというふざけたオプションが必要でした。(^^) この後も順調に (?) 開発はすすみ、4.5 カーネルのリリースでついにこの機能が stable となったようで、"__DEVEL__" というプレフィックスも不要になりましたし、正式な機能で「まともなふ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
