スライドが公開されてるのでそっちを見た方が正確です。
けど、一応メモったものを載っけておきます。
安定稼働と高性能を支える要素
問題の大半はディスクI/O
製品の品質に対する目を向ける
- 「俺が安定版と言えば安定版なんだ！」というものもある
一般解を求めすぎない
- 汎用性を高くすればするほど効率は悪くなる
良いところよりも悪いところを見る
- 悪いクエリが1個でもあると、すべてが止まることがある
- ボトルネックになっていないところをどれだけ最適化しても全体のパフォーマンスはたいして変わらない
データベース以外にも目を向ける
アプリケーションの性質をある程度知っておく
OSSを責任転嫁の道具にしてはいけない
Linuxのチューニングと安定運用
メモリ管理
メモリを十分に取り、ダイレクトI/Oを活用する
- innodb_flush_method=O_DIRECT
スワップ制御とOOM Killer
スワップサイズをゼロにしてはいけない
スワップの調整
メモリ領域の割り当て
- tcmalloc()
- innodb_use_sys_malloc=1 に加え LD_LIBRARY_PATH や LD_PRELOAD で tcmalloc などのアロケータを指定
- 必要以上にメモリ割り当てをしない
I/Oスケジューラ
I/Oスケジューラの性能差(InnoDB)
- 5.3 ではデフォルト cfq でも変わらない
- 5.4 は I/Oスレッドが 16本、5.1では2本
- # echo 100000 > /sys/block/sdX/queue/nr_requests
- 簡易的なストレージだと影響が大きい
- 原則：ルートパーティションとデータファイル用パーティションは分ける
ext3
- 巨大ファイルの削除に時間がかかる
- innodb_file_per_table を使うような場合に注意
- 同じファイルに対して並列に書き込むことができない
- 大量の数のファイルを扱う場合 dir_index オプションで作成して探索を高速化する
- ジャーナリングモード journal, ordered(デフォルト), writebackから選択可能
ファイルI/Oと同期書き込み
- 上書きと追記の違いに注意
- 追記の方がずっと遅い
使いこなしたいコマンド類
iostat
- r/s w/s svctm %util に注目
- %util = (r/s+w/s)*svctm
- %util はあまりあてにならない
- %util よりも svctm を見た方が良い
mpstat
- CPUコア単位で統計
- vmstat は平均値
Oprofile
- どの関数がCPUリソースをもっとも消費したかを簡単に特定できる
- CPU使用率が低い場合には役に立たない
- 全スレッドのスタックトレースを取る機能がある
- Solaris の DTrace に匹敵する
- 監視対象のプロセスがクラッシュしたという報告が随所にある
ネットワークとデータベース接続
カーネルパニックとHA構成
