Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ゆるかわLinux
Search
tdak
May 13, 2013
Technology
16
3.6k
ゆるかわLinux
2012/10/13に行われた「ゆるかわPHPの会#1」で発表した資料です。
Linuxカーネルについてゆるく話しました。
間違いやツッコミなどありましたらご連絡いただけると嬉しいです。
tdak
May 13, 2013
Tweet
Share
More Decks by tdak
See All by tdak
1周回って、 辿り着いた技術コミュニティの話 / kichijoji.pm #26 tech community
tdak
0
1.2k
Ruby on Rails 最初の一歩
tdak
5
4.7k
tqrk10
tdak
1
1k
PHPer.rb
tdak
1
560
BEAR.Sunday meet up#2
tdak
0
310
オブジェクト指向と設計の話
tdak
4
4k
Ruby * Scratch * CoderDojo
tdak
0
1.8k
Rubyをはじめたときにつまずいたこと
tdak
0
2.2k
Other Decks in Technology
See All in Technology
スタックチャン家庭用アシスタントへの道
kanekoh
0
120
推し書籍📚 / Books and a QA Engineer
ak1210
0
140
60以上のプロダクトを持つ組織における開発者体験向上への取り組み - チームAPIとBackstageで構築する組織の可視化基盤 - / sre next 2025 Efforts to Improve Developer Experience in an Organization with Over 60 Products
vtryo
3
1.9k
ロールが細分化された組織でSREは何をするか?
tgidgd
1
420
振り返りTransit Gateway ~VPCをいい感じでつなげるために~
masakiokuda
3
210
SRE不在の開発チームが障害対応と 向き合った100日間 / 100 days dealing with issues without SREs
shin1988
2
2k
QuickSight SPICE の効果的な運用戦略~S3 + Athena 構成での実践ノウハウ~/quicksight-spice-s3-athena-best-practices
emiki
0
290
Talk to Someone At Delta Airlines™️ USA Contact Numbers
travelcarecenter
0
160
AIエージェントが書くのなら直接CloudFormationを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさ
watany
18
7.6k
AI エージェントと考え直すデータ基盤
na0
20
7.9k
名刺メーカーDevグループ 紹介資料
sansan33
PRO
0
820
Bill One 開発エンジニア 紹介資料
sansan33
PRO
4
13k
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.7k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
The Straight Up "How To Draw Better" Workshop
denniskardys
235
140k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
How to train your dragon (web standard)
notwaldorf
96
6.1k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
The Cult of Friendly URLs
andyhume
79
6.5k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
GitHub's CSS Performance
jonrohan
1031
460k
Code Review Best Practice
trishagee
69
19k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
It's Worth the Effort
3n
185
28k
Transcript
ゆるかわLinux
今日話したいこと。
今日話したいこと 「LL で Web アプリ作るよ!」 っていう Web エンジニア LL でコードさえ書ければOK!
という雰囲気でもない...
今日話したいこと 知っておきたいこと * サーバのこと * ネットワークのこと * データベースのこと * フロント、デザインのこと
...いろいろ
今日話したいこと PHP × Web アプリケーション よくある開発環境 L AMP とか L
APP とか...
今日話したいこと Linux についても知っておきたい Linux とはどんなものか? 裏でどんなことしてる?
今日話したいこと Linux... Linux カーネル?
ということで、今日は Linux カーネルのお仕事を 中心に話したいと思います。
カーネルのバージョンは 2.6.x ですごめんなさい
Linux カーネルって? OSの中で核となるプログラム。 アプリケーションが動作するための 基本環境を提供。
Linux カーネルがやってること。 * ハードウェアの制御 * プロセス管理 * メモリ管理 * ファイルシステム
* ネットワーク ...など Linux カーネルって?
まずは基本機能について。
Linux カーネル内では様々な処理が 非同期に動作する。 この動作を制御するため、 Linux カーネルは 次のような機能を持っている。 カーネルの基本機能
* システムコール * プロセススケジューラ * 割り込み * 同期と排他 * 時計
カーネルの基本機能
システムコールとは プロセスがカーネルに対して 要求を行うためのインタフェース。 システムコール
カーネルの機能(関数)は プロセスから直接呼び出せない。 システムコールを通して呼び出す。 システムコール
カーネルの機能を呼び出す際に システムコールを通すことで、 ほかのプロセスや カーネル本体の動作が 不安定にならないよう保護できる。 システムコール
たくさんのプロセスが同時に走る。 処理を行うCPUの数は限られている。 カーネルはプロセスの中から もっとも動作させるにふさわしい プロセスに実行権限を与える。 プロセススケジューラ
ハードウェアやネットワークからの シグナルを受け取るしくみ。 割り込み
たくさんのプロセスが同時に走る。 なので、共有しているメモリの内容が 書き換えられてしまう可能性が... 排他制御が必要! シングルコアでもマルチコアでも! 同期と排他
時計。 時計
ファイルシステムは OS の中心機能。 ファイルシステムは記憶装置上のデー タに対して「ファイル」という形式を 通して一貫したアクセス手順(開く、 読む、書く、閉じる)を提供する。 ファイルシステム
ファイルシステムのおかげで、 カーネルはファイル内のデータ型を 意識する必要がない。 そんなのは利用する アプリケーション側が 意識すればいいよ! ファイルシステム
プロセス管理について。
そもそもプロセスって? プログラムが動いている状態のこと。 OSが管理する処理の単位。 ( OS によってはタスクと呼ばれる )
そもそもプロセスって? Linux だと ps コマンドで プロセスの状態を確認できる。 * ps … process
status pid(各プロセスが持つ固有のID)とか プロセスの名前とか…
そもそもプロセスって? それぞれのプロセスは 固有のコンテキストを持つ。 ...コンテキスト?
そもそもプロセスって? コンテキストとは... * 一連の処理の流れ * 動作するために必要なプロセス空間 * 動作するためのレジスタ値
プロセスは fork システムコールを 呼ぶことで生成される。 ...誰がプロセスを生成(fork)する? プロセスの生成
プロセスには親子関係がある。 プロセスを生成したときに、 生成した側が親になり、 生成された側が子になる。 プロセスの生成
プロセスは複数の子プロセスを 持つことができる。 また、その子がさらに子を 持つことができる。 プロセスの生成
Linux プロセスは fork システムコールを発行した プロセスの子として生成される。 このとき親プロセスが保有する情報は 子プロセスにそっくりコピーされる。 プロセスの一生
親プロセスの fork システムコールに より発行された子プロセスは... * exec システムコールで目的の処理 を実行開始。 * 処理終了時に
exit システムコール を発行する。 プロセスの一生
子プロセスが exit したとき... * 親プロセスは wait システムコール で子プロセスの終了を待ち合わせる ことができる。 *
親プロセスで wait システムコール が発行されない場合、子プロセスは 保留状態(ZOMBIE)となる。 プロセスの一生
プロセスの一生 (1) 親プロセスが wait したとき (2) 親プロセスが wait しなかったとき 親プロセスが先に死んだとき
特殊なプロセス init プロセス プロセス ID が 1 のプロセス。 すべてのプロセスの先祖。 親プロセスを失った
子プロセスの親にもなる。
特殊なプロセス idle プロセス 実行できるプロセスが何もないときに 実行されるプロセス。 プロセス ID が 0 で
CPU の分だけ 生成される。 ps 等で見ることはできない。
特殊なプロセス カーネルスレッド カーネルだけで動作して ユーザーコードを実行しない 特別なプロセス。 これも init プロセスの子プロセス。
たくさんのプロセスが同時に走る。 処理を行うCPUの数は限られている。 カーネルはプロセスの中から もっとも動作させるにふさわしい プロセスに実行権限を与える。 プロセス切り替え処理
プロセスディスパッチャ プロセス切り替えを行う機能。 プロセス切り替え処理
プロセススケジューラ 実行可能なプロセスを監視し、 どのプロセスに実行権を与えるか 判断して、プロセスディスパッチャに 切り替え要求を出す機能。 プロセス切り替え処理
※イメージ図 プロセス切り替え処理 実行待ちプロセス 待機状態プロセス 実行可能プロセス
* ユーザ側から実行されるプロセス * ハードウェア、ネットワーク からの割り込み 割り込みの方が優先度高い! プロセス切り替え処理
メモリ管理について。
ふたつのメモリ管理 Linux カーネルは 2種類のメモリ管理を行う。 * 実メモリ管理 * 仮想記憶
ふたつのメモリ管理 仮想記憶は高価で容量が少ない 実メモリを効率よく管理できるよう、 もともとUNIXで実装されていた手法。 しかし最近は実メモリも容量が 大きくなってきたので、 この辺のメモリ管理機能も 変わる可能性があるとかないとか。
実メモリ管理 RAMチップ内のメモリ領域 (実メモリ)を管理すること。
実メモリ管理 Linux カーネルは実メモリを 「ページ」という単位で管理する。 ページは仮想メモリを利用したときに CPUがサポートする メモリ管理の最小単位。
仮想記憶 アプリケーション(プロセス)から 参照するメモリアドレスは実メモリの アドレスではなく、 仮想的な領域のアドレスとなる。
仮想記憶 物理的に分散したページを集めて 仮想的に連続したアドレス空間を 作るのもカーネルのしごと。
仮想記憶 (1) プロセスが「メモリほしい!」と 要求する。 (2) カーネルがメモリに空いてる アドレスを確認する。 (3)
メモリが空いてるアドレスを返す。 (4) プロセスにアドレスを返す。
仮想記憶 ※イメージです
仮想記憶 アドレス空間はプロセスごとに 割りつけられるので、各プロセスは 自分のアドレス空間を自由に利用す ることができる。
仮想記憶 アプリケーション側で意識しなくちゃ いけないことが減る。 * ほかのプロセスとメモリが競合しな いか、とか * メモリのアドレスがどこから始まる のか、とか
スワップ 最近アクセスされた仮想ページのみを 実メモリに置いておき、 ほかは2次記憶装置に退避しておく ことで、実際に搭載されている 実メモリよりも大きなメモリを使用し ているように見せることができる。
スワップ これがスワップ。
スワップ とは言っても2次記憶装置。 メモリに比べると速度は遅い。 あまり発生させたくない。 スワップ必要なの?
ある日のカーネルさん。
カーネルさんの仕事
カーネルさんの仕事
カーネルさんの仕事
カーネルさんの仕事 _人人人人人人人人人_ > 突然のOOM Killer <  ̄^Y^Y^Y^Y^Y^Y^Y^ ̄
Out of Memory Killer Linux カーネルには メモリが確保できなくなったとき、 無作為に選んだプロセスを殺す 素敵な機能がある。
Out of Memory Killer Malloc で実メモリ+スワップ よりも多くメモリ確保できる ↓ 実際メモリを確保しようとして失敗 ↓
_人人人人人人人人人人人人人人人人人人人_ > OOM Killer or カーネルパニック <  ̄^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^ ̄
Out of Memory Killer 大事なプロセスを殺されたり、 カーネルパニックで全滅するより スワップした方がましなことも ありますよね。
Out of Memory Killer 大事なプロセスは殺さないよう 設定可能だったりもするけど、 やっぱりチューニング大事! * Apache の
Max Clients とか * MySQL の buffer_pool_size とか
で、これ結局何の役に立つの?
役立ちそうなこと きっとたぶんいろいろある! * パフォーマンスを意識した Web アプリケーションづくり * パフォーマンスチューニング *
トラブル対応 * ミドルウェア選定
役立ちそうなこと たとえば Web サーバを選ぶとき... * apache? nginx? * prefork? worker?
「要件に向いているのはどれか」 「なぜそれを選ぶのか」 選ぶ理由はパフォーマンスだけじゃないけど...
参考書籍など。
Linux のしくみ的なところ Linuxカーネル解読室 高橋浩和・小田逸郎・山幡為佐久 /ソフトバンククリエイティブ プロのためのLinuxシステム 構築・運用技術 中井悦司/技術評論社
ソースコード読みたい人向け Linuxカーネル解析入門 [増補版] 平田豊/工学社 デーモン君のソース探検 BSDのソースコードを探る 冒険者たちのための手引き書 氷山素子/アスキー
もっと詳しく知りたい がっつり詳しく仕様を知りたい人には 「詳解 Linuxカーネル」がよさそう。 安心のオライリー。
まとめ。
Linux もかわいいけど FreeBSD もかわいいよ!
ありがとうございました。