eks クラスター障害のふりかえり
ストレッチ⌗
今日の開脚幅は開始前155cmで、ストレッチ後161cmだった。開始前の数値が悪いけど、とくに調子が悪いというわけでもなかったので計測の仕方がよくなかったか、たまたま足の開き方が悪かったかといったところだろう。昨日、高級時計と投資の話しを聞いたのでトレーナーさんとお金があったら何に使う話しが盛り上がった。トレーナーさんも庶民的な方でとくにお金があっても贅沢をしたいというものでもないらしい。私も改めてお金があったら何がしたいかを考えてみてもお金を使ってやりたいことはとくにないなというのが率直な思いでもある。私には自分がやったことのないことをやってみたいという思いしかなく、そのためにお金を使ってきた側面も多々あるけれど、お金を直接的に使って何かをやるというよりも、生活できるだけのお金があれば、その時間に自分がやったことのないことに挑戦して人生を楽しむということぐらいしかやることはないんだなと、トレーナーさんと話していて考えたりしていた。
os 雑談⌗
午後から昨日の障害のふりかえりといくつか調査をして、夕方におがわさんに声をかけたら話し相手になってくれると返ってきた。障害のふりかえりをした後に課題管理の雑談もしていて4時間弱ぐらい話してた。私自身、反省しないといけないとは思っていたのでおがわさんはちゃんと指摘をしてくれた。この歳になると私を叱ってくれる人はいない。たまに失敗したときにおがわさんに話して然るべき指摘をしてもらえるのは本当にありがたい。
kubernetes がどうやって動いているのかを理解して運用しているのか?
コンピューターがどうやって動いているのかを理解しているのか?
私が未熟で理解できていなかったからこんな障害を見過ごしていた。システム障害が発生しても人生は終わりじゃない。反省してから次につなげる。おがわさんと話していて、os の仕組みや機能についていくつか教えてもらった。
- 制限対象の違い
- ulimit はユーザーに対する制限
- /proc ファイルシステムはシステムに対する制限
/proc/sys/kernel/pid_max
は kernel のデフォルト値として 32768 が設定されているが、systemd を使っていれば値を変更している場合がある- 私の ubuntu マシンだと 4194304 が設定されていた
- コンテナ内から
/sys/fs/cgroup/memory/memory.usage_in_bytes
をみると、コンテナが使っているメモリ量なのか?- cgroup の使い方次第で変わる、システムの値かもしれないしコンテナの値かもしれない
- ゾンビプロセスに残っている情報は親プロセスが子プロセスの統計情報を取得するために必要なもの
- どんな子プロセスも一時的にはゾンビプロセスになる
- kernel の task_struct 構造体やその他の構造体、リンクしている情報などをすべて足すと1つのゾンビプロセスが10数 KiB 程度ではないか
- 仮に 15 KiB として 32000 個のゾンビプロセスがあると約 469 MiB のメモリ量になるのでだいたい数字があう
- ユーザー空間とカーネル空間の違いを理解できるようになった方がよい
- システムコールの fork がエラーになるのはシステムがおかしいとすぐに気付けるはず
- fork がエラーになる原因として考えられるのはメモリを確保できないか、pid_max に達したか、いずれにしてもエラーコードをみれば推測がつくのではないか
- システムコールの fork がエラーになるのはシステムがおかしいとすぐに気付けるはず
- 環境にログインできるのであれば strace を使えば障害調査に役立つ
- 私が普段使っていないツールなので障害のときにとっさに扱えるよう練習しておく