ディスクが遅い？ - ゆううきメモ

書籍 Systems PerformanceのChapter 1の1.9節 Case Studiesの話。

データベースチームから、データベースサーバのディスクが遅いと言われる。
ディスクが遅いということが、データベースの問題を引き起こす直接の原因かどうかはわからない。
データベースチームに下記の質問をしてみた。
- 現在、データベースの性能に問題はあるのか？どのようにしてそれを測定したのか？
- 問題はどれくらいの間起きているのか？
- 最近、データベースに何か変更を加えたか？
- なぜディスクを疑ったのか？
返答があった。
- 1,000ms 以上のスロークエリがある。
- 普段はそんなにスロークエリがないが、先週の間に1時間あたりで12倍の数になった。
- モニタリングツールをみると、ディスクがビジーになっていた。
USE(The Utilization Saturation and Errors)メソッドでリソースボトルネックを調査した。
- 確かに、ディスクI/Oの利用率は高く、80%だった。CPUやネットワークの利用率はもっと低い。
- 先週からCPU利用率は変わってない。
- モニタリングツールは、ディスクの飽和やエラーの統計をだしてくれない。
USEメソッドを達成するために、サーバのログを見たり、コマンドを叩いたりしなければなかった。
- /proc からディスクのエラーカウンタをチェックした。ゼロだった。
- 1秒のインターバルでiostatを走らせて、利用率(utilization)と飽和(saturation)を観察した。
- サーバモニタリングツールは1分平均で、80%を報告したが、それは1分のインターバルだった。
- 粒度が1秒だと、頻繁に100%になって、飽和とディスクI/Oのレイテンシが悪化しているのことがわかった。
この現象がデータベースを本当にブロックしているかを確認するために、動的トレーシングツール(Dtraceなど)を使った。
- クエリ処理のうち、ms単位でファイルシステムのreadがデータベースをブロックしていることがわかった。
なぜブロックしているのか？
- ワークロードの性質をみるために、iostatでIOPS、スループット、平均ディスクI/Oレイテンシ、read/writeの比率を測定した。
- これらの情報から、平均I/Oサイズとアクセスパターン（ランダムかシーケンシャルか）を計算した。
- より詳細をみるために、ディスクI/Oレベルのトレーシングを使った。
- しかし、これらの調査はディスクの負荷が高いとわかるだけで、ディスクそのものが問題ではないことがわかってきた。
データベースの負荷は増えたのか？
- データベースチームはNoと答えて、クエリのレート（モニタリングツールには表示されない）には変化がないと応えた。
- CPU利用率に変化なかったことと整合性がとれるようにみえる。
CPU負荷が上がらずに、ディスクI/O負荷が上がることはありえるのかを考えた。
- 同僚はファイルシステムのフラグメンテーションではないかと言っていたが、ディスクの使用量はたったの30%だった。
ディスクI/Oの真の原因をドリルダウンすることはできそうだが、時間がかかりそうだった。
- カーネルのI/Oスタックの知識から、ディスクI/Oはファイルシステムキャッシュ（ページキャッシュ）ミスからたいてい引き起こされることを思い出した。
ファイルシステムキャッシュのヒットレートは現在91%であることをチェックした。
- 一見高いようにみえるが、比較するための過去のデータがなかった。
- 似たようなワークロードの他のデータベースサーバのログをみた。ファイルシステムのキャッシュヒットレートが97%を超えていた。
- ファイルシステムキャッシュのサイズが他のサーバよりもかなり大きいことがわかった。
ファイルシステムキャッシュサイズとメモリの使用状況に関心が移った。
- 開発チームはアプリケーションのプロトタイプを持っていて、プロダクションレベルの負荷がないわりに、そのアプリケーションがメモリを徐々に食いつぶしていた。
- したがって、ファイルシステムキャッシュ用のメモリが足りなくなっていた。
アプリケーションを停止させて、他のサーバに移した。
- その結果、モニタリングツールでディスクI/O利用率が下がって、ファイルシステムキャッシュが元に戻った。スロークエリはゼロになった。