makurosu8 blog

ゲーム開発全般/勉強会レポート/雑記

『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シリーズ)

[Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ)