『Web開発者のための大規模サービス技術入門』五日目
OSのキャッシュと分散
VFS
ディスクを操作するデバイスドライバと
OSの間にはファイルシステムが挟まっている
(Linuxだとext3,ext2,ext4,xfsなど)
そのファイルシステムの上にはVFS(仮想ファイルシステム)がいる
概要
インターフェイスの統一をすること
このVFSがページキャッシュの仕組みをもっている
どんなファイルシステム、ディスクシステムを使っても
同じ仕組みでキャッシュされる
VFSの役割は・・・
・ファイルシステム実装の抽象化
・ページキャッシュ
Linuxはページ単位でディスクをキャッシュ
例えば・・・
2GBのメモリで500MBをOSがプロセスに割り当て
4GBのファイルをキャッシュできる?
答え・・・
出来る。OSはブロック単位でファイルの一部分をキャッシュする
ここではページ単位の4KBだけキャッシュする
ページ=仮想メモリの最小単位
LRU
メモリの余裕が1.5GBあって4GB全部読んだらどうなる?
仕組みとしてLRU、一番古いものを廃棄
一番新しいものを残すという形になっている
よって、DBをずっと動かしていればキャッシュが最適化され
起動直後より後の方が負荷、ファイルI/Oが下がっていく
(補足)どのようにキャッシュされるのか
Linuxはファイルをiノード番号という番号で識別
そのファイルのiノード番号とそのファイルがどこから始まるか
のオフセットの2つの値をキャッシュ
この仕組みでファイルの一部分がキャッシュできる
ファイルが大きくても小さくても同じ速度でキャッシュできる
(RadixTreeという工夫されたデータ構造のおかげ)
『Web開発者のための大規模サービス技術入門』四日目
OSのキャッシュと分散
OSのキャッシュ機構
そもそもOSにはディスクのアクセスを速くする仕組みがある
ページキャッシュ
OSは「仮想メモリ」機能をもっている
仮想メモリ=論理的なリニアアドレスを物理的な物理アドレスに変換
メモリには32ビットの番地が付いてる(0x12345678)
プロセスがメモリが欲しいときOSは空いているメモリを返すが
アドレスを違うアドレスに変換する
なぜそうするか?
決まった地点から使えたほうがプロセスが扱いやすいため
(0x0000000に変換する)
ポイント
OSはメモリを直接渡すのではなくカーネルの中で仕組みを抽象化している
備考
OSはメモリを確保する時に1バイトずつではなく
4キロバイトほどブロックを確保している
この1ブロックをページと言う。OSは最低1個以上のページを確保
Linuxページキャッシュの仕組み
OSは確保したページをメモリ上ずっと確保し続けている機構を持っている
ページキャッシュの仕組み
1.OSがディスクから4キロバイトのブロックを読み出し
2.メモリ上に配置(プロセスは仮想メモリだけアクセス出来る)
3.OSは仮想メモリの番地をプロセスに教えてあげる
4.OSが仮想メモリにアクセス
5.プロセスがデータを読み終えても仮想メモリは開放されない
6.次に別のプロセスが同じディスクにアクセスする際は残しておいたページを使用
ページキャッシュの身近な効果
Linuxではディスクにデータを読みにいくと必ずメモリにいってキャッシュされる
したがって、2回目以降のアクセスが速くなる
OSはずっと起動しておくと速くなる
起動直後はキャッシュがないのでディスクI/Oは発生しやすく重い
『Web開発者のための大規模サービス技術入門』コラム1
具体的なロードアベレージとCPU負荷とI/O負荷の確認方法
top コマンド
load average: 0.52, 0.44, 0.37
左から順に1分、5分、10分の単位時間当たりの待たされたタスクの数
つまりはどの程度のどの程度のタスクが待たされたか
この値が高ければ遅延している
CPU負荷とI/O負荷
sar コマンド
CPUバウンドなサーバ
%user or %system が高く%idleが少ない
00時00分01秒 CPU %user %nice %system %iowait %steal %idle
00時10分01秒 all 60.29 0.00 1.50 0.00 0.00 40.70
00時20分01秒 all 59.12 0.00 1.56 0.00 0.00 40.19
I/Oバウンドなサーバ
%iowait が高い
00時00分01秒 CPU %user %nice %system %iowait %steal %idle
00時10分01秒 all 0.29 0.00 1.50 22.00 0.00 99.70
00時20分01秒 all 0.12 0.00 1.56 22.00 0.00 99.19
『Web開発者のための大規模サービス技術入門』三日目
スケーリングの要所
・スケールアップ
高価で速いハードウェアを買って性能アップ
・スケールアウト
安価で普通の性能のハードウェアを並べてシステム全体の性能を稼ぐ
現在はスケールアウトが主流
・コストが安い
・システム構成が柔軟
CPU負荷(APサーバ)の場合はスケールアウトは簡単
・データを持っていないので横展開してアクセスを分散するだけでOK
I/O負荷(DBサーバ)の場合はスケールアウトは複雑
・データ書き込みは分散できない。データ同期ができない
大規模データを扱うための基礎知識
3つの勘所
1.いかにメモリで済ませる事が出来るかが重要
・1日目で説明したとおりディスクI/Oは遅いため
2.データ量の増加に強いアルゴリズムを使う
・線形検索をlogオーダアルゴリズムを適用するなど
3.テクニックを使う
・圧縮や検索技術など
基礎知識
1.OSのキャッシュ
2.分散を考慮してRDBMSを運用する
3.大規模な環境でアルゴリズムとデータ構造をを使っていく
『Web開発者のための大規模サービス技術入門』二日目
『推測するな、計算せよ・・・』単一ホストの性能を引き出す
ボトルネックを見極める
・ロードアベレージを確認
・CPU、I/Oどちらがボトルネックか確かめる
ロードアベレージを見る
・ロードアベレージ?
システム全体の負荷を示す指標
・高かった場合は?
CPU、I/Oどちらがボトルネックか確かめる
CPUがボトルネックの場合
・ディスクやメモリに負荷がかかってない理想的な状態
Webサーバを増やせば解決
・なにかのプロセスが暴走している
どのプロセスの負荷が高いのか調べてプログラム修正
I/Oがボトルネックの場合
・特定のプロセスが消費しすぎている
どのプロセスの消費しているのか調べる
・搭載メモリが不足している
メモリ増量 or 分散
・プログラムの不具合で消費しすぎている
プログラム修正
・そもそもデータ量が多すぎる
まとめ
・ボトルネックを見極めるのが大切
・CPUがボトルネックの場合は理想的な状態で対応は容易
・I/Oがボトルネックの場合は対応が大変
『Web開発者のための大規模サービス技術入門』一日目
メモリとディスクの速度差について
メモリとディスクでは検索に10万倍から100万倍、転送に100倍の速度差がある
・何故?
メモリは電気的な部品なので検索速度にに物理的構造は関係ない
ディスクは検索に物理的な動作を伴っているので遅い
CPUと繋がるバスにも差がある
ディスクではなくメモリを使うべき
・問題
メモリ内で計算できないとディスクに検索にいってしまう
これを回避する必要がある
まとめ
・ディスクI/0を減らしメモリを効率的に使いたい
『Web開発者のための大規模サービス技術入門』読み始め
Web開発者のための大規模サービス技術入門を読み始めました。
今のお仕事にたくさん役立ちそうだったのでメモしてこうと思います。
何故この本を読み始めたの?
- 現在サービスを行っているソーシャルゲームのマスタDB負荷が高い
- アクセスが集中するイベント直後にAPIレスポンスが大幅にあがる
- ボトルネックを確かめ解決したい
ここらへんを解決して行きたいです。
[Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ)
- 作者: 伊藤直也,田中慎司
- 出版社/メーカー: 技術評論社
- 発売日: 2010/07/07
- メディア: 単行本(ソフトカバー)
- 購入: 80人 クリック: 1,849回
- この商品を含むブログ (128件) を見る