Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ゆるかわLinux
Search
tdak
May 13, 2013
Technology
16
3.5k
ゆるかわ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.1k
Ruby on Rails 最初の一歩
tdak
5
4.6k
tqrk10
tdak
1
1k
PHPer.rb
tdak
1
480
BEAR.Sunday meet up#2
tdak
0
290
オブジェクト指向と設計の話
tdak
4
3.9k
Ruby * Scratch * CoderDojo
tdak
0
1.8k
Rubyをはじめたときにつまずいたこと
tdak
0
2.2k
Other Decks in Technology
See All in Technology
【Oracle Cloud ウェビナー】【入門&再入門】はじめてのOracle Cloud Infrastructure [+最新情報]
oracle4engineer
PRO
2
100
AWS re:Invent 2024 予選落ちのBedrockアプデをまとめて解説!
minorun365
PRO
2
220
LLMの気持ちになってRAGのことを考えてみよう
john_smith
0
190
サービスの拡大に伴うオペレーション課題に立ち向かう / 20241128_cloudsign_pdm
bengo4com
0
760
コンパウンド戦略に向けた技術選定とリアーキテクチャ
kworkdev
PRO
1
3.9k
静的解析で実現した効率的なi18n対応の仕組みづくり
minako__ph
2
2.3k
Entra ID の多要素認証(Japan Microsoft 365 コミュニティ カンファレンス 2024 )
murachiakira
0
1.5k
Nutanixにいらっしゃいませ。Moveと仮想マシン移行のポイント紹介
shadowhat
0
180
.NET のUnified AI Building Blocks 入門...!
okazuki
0
110
LLMを「速く」「安く」 動かすには / CloudNative Days Winter 2024
pfn
PRO
4
1.1k
"とにかくやってみる"で始めるAWS Security Hub
maimyyym
2
210
SLMをエッジAIとして検証してみて分かったこと
iotcomjpadmin
0
110
Featured
See All Featured
YesSQL, Process and Tooling at Scale
rocio
169
14k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8.2k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
24k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
Making Projects Easy
brettharned
115
5.9k
Art, The Web, and Tiny UX
lynnandtonic
297
20k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
27
4.3k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
47
2.1k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
[RailsConf 2023] Rails as a piece of cake
palkan
52
5k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
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 もかわいいよ!
ありがとうございました。