2. Mobage運用技術Web編

Mobage Webサーバ機の資源管理について

登壇者：DeNA樋口様

2-1. Mobageの佐波郡構成について

1. 基本、LAMP
2. WebサーバとDBサーバが大部分
3. Apache と FastCGI が同居
4. FastCGIはマルチプロセス型サーバ
5. ゲームごとに分離されているわけではない
- ゲーム間連携が簡単にできるメリットがある
6. オープンプラットフォームはアプリごとに独立している

2-2. Webサーバ機の資源消費について

1. Webサーバ機は、CPUまたは、メモリがネック
2. メモリ使用量が、1Gbyteを超えてしまう

2-2-1. FastCGIワーカ数の管理

1. サーバ1台あたり 〜100プロセス程度
2. CPUコア数の2,3倍は必要
3. 1つのリクエストを処理する間の半分以上の時間はネットワークIO街などでsleepしているから
4. ワーカーは、多いほど、耐障害性が高まる
5. 多すぎるとメモリ不足になる

2-2-2. デバッガを使った状況モニタリング

1. 走っているプロセスにデバッガをアタッチし、アタックとレースをとり、すぐにデタッチ
2. 前プロセスのスタックトレースを一定周期で取得
3. httpdとFastCGIが対象
4. gdbを使っていたが、bulkdbgというものを作成し利用している
- デタッチしたあとにシンボル解決している
5. Mobageでは、約5秒おきにhttpdとFastCGIの前プロセスのスタックトレースを取得、ログ出力
6. 利用状況モニタリングと障害調査に利用
- オーバヘッドはほとんどなし
7. accept()でブロックしているワーカーの数が減ってきたら枯渇が近い
- メールで警告
8. ログを見れば分かる状態

2-2-3. 障害調査の手法

1. gdb等で確認できるのは、Cのスタック
2. Perlのスタックトレースも見たい
3. gdbperl.pl というものを作成
4. Perlがデバッグシンボル付きでコンパイルされていないと動かない
5. 本番でも使っている
6. NYTProfでプロファイルデータの取得
7. 状況を把握できないよな自体は現状ほぼなくなった

2-3. メモリ利用効率化

基本

1. 独立したPerlモジュールにしている

Perlモジュールプリロード

1. 昔のMobage : forkされた各ワーカがperlをexec、モジュールを読み込みリクエスト処理
2. 今のMobage : アプリのもウールを読み込んだ後にワーカープロセスをforkしリクエスト処理
3. forkのタイミングで、Socket等を開いたままだと問題を起こすことがある

- 処理の実行順序が変わることによる影響があった
- 移行後は、メモリの使用量は半分になった

OSページキャッシュの効率化

1. アプリが履くログファイルがキャッシュされてしまう
2. メモリをけちると、ログ回収のタイミングでswapしていた
3. posix_fadvise

- 本来ファイルを利用するアプリ自体が宣言するもの
- 10秒に1回、daemonを動かしている
- ログファイルがキャッシュに乗らなくなった