トラブルシューティングの極意―達人に訊く問題解決のヒント

第5回 [サーバ・インフラ・ネットワーク編]こんなときどうする!?―ネットワークやサーバのチェックポイント

この記事を読むのに必要な時間:およそ 3 分

トラシュー事例(上級編)
「Flashストレージを導入し,遅くなったデータベース」

とある日,1通のメールが届きました。筆者が取り扱った案件で,FlashストレージとMySQLを組み合わせたのですが,そのシステムでレプリケーションが遅延し,本来の性能の10%も得られないという内容でした。それに加えて,普通にDBを運用していると性能が出ないのに,同時に読み込みワークロード注6を実行していると,負荷が増しているにもかかわらず,データベースの処理性能が10倍近くに跳ね上がるというのです図3)⁠

図3 問題を示すIOPSグラフ(イメージ)

図3 問題を示すIOPSグラフ(イメージ)

そんな不可解な状態だったので,早速,実機を確認しに伺いました。この問題で使用されていたMySQLは,レプリケーションのスレーブとなっていました。MySQLであればレプリケーションを受けている際に遅延している秒数が確認できますが,レプリケーションを受けていると,その遅延秒数が増えていきます注7)⁠HDDでのライトバックキャッシュが有効に動作する状況であれば,下手なFlashメモリストレージより最高性能が出ることもありますが,しかしHDDで捌かれたワークロードがまったくFlashストレージで捌けないというのは,何か問題がありそうです。

まずは,ログに何か出力されていないかを確認しました。ログには,ソフトウェアの開発中のデバッグ情報であったり,もしくはユーザがそのソフトウェアを利用する際に有益となる情報が出力されるものですから,問題解決の糸口が見つかればラッキーです注8)⁠残念ながら,今回はOSやミドルウェアのログには,解決の糸口となりそうな内容はありませんでした。

次に,MySQLのパラメータをひとつひとつ変更しながら状況が変化するかを確認していきました。問題の糸口が何かをつかめるまでは,地道な作業です。しばらくして,バイナリログの同期書き込みを無効化すると問題が大幅に改善し,バイナリログの書き込み速度に関連した問題だと絞り込めました。

客先での現地調査も一段落し,お客様と相談して,まずは暫定対処としてバイナリログの同期書き込みをオフで利用いただくことにしました。アプリケーションやミドルウェアの特性を把握していれば,何が起きているか,抱えている問題がどのような影響を与える可能性があるか,どのような暫定対処策があるかをある程度推測,判断できます。本来であればデータの永続性を保証するために,同期書き込みを勧めたいのですが,プライマリデータが別にも保存されており,有事の復旧も可能であると見込み,同期書き込みなしでも最低限の信頼性を保って運用いただけるのでは,と判断しました。

その後,⁠バイナリログの同期書き込みがなぜ想定より遅いのか」に焦点を絞り,検討を始めました。経験上,先の構成であれば,同期書き込みを行ったとしても,もっと高い性能が得られるはずです。MySQLのInnoDBストレージエンジンの場合,トランザクションの永続性を保証するため,ログ書き込みが終わった時点でトランザクションが完了します。このため,バイナリログの同期書き込みが遅延すれば,それだけトランザクションに必要な時間が増えることになります図4)⁠

図4 ログの同期書き込み

図4 ログの同期書き込み

問題の再現方法がわかったため,同様の問題を再現させるための環境を手元に構築し,より根本的な原因を調査しました。ftraceでカーネル内のブロックI/Oのイベントを調べたところ,特定のLinuxカーネルに,デバイスへのI/Oがすぐ開始されない現象が確認されました。この場合,数ミリ秒してからカーネル内のウォッチドッグタイマが発動し,I/Oが遅れて開始されることがわかりました注9)⁠最終的には社内のLinuxカーネルメンテナが,ドライバに細工を入れて問題を解消しました。

注6)
たとえば,dd if=/dev/fioa of=/dev/null bs=512
注7)
SHOW SLAVE STATUSで取得できるSeconds_Behind_Masterの秒数が増えていく状況。
注8)
逆に,検証や構築,試験を終えたあとには,ログや統計情報の出力レベルが高く設定され,CPU使用率が高まり,性能低下が生じているケースがある点も注意が必要です。
注9)
私の場合は偶然にも社内にLinuxカーネルコミッターがおり,彼らにより問題解決が可能であったことに救われましたが,まわりの同僚や飲み仲間でも,何か困ったときに助言,支援し合えるような横のつながりは大事だと思います。
調査・分析のとっかかりになるポイント集

最後に,問題の調査・分析にあたり,まずチェックしたいポイント(ログファイル,コマンド)を紹介します。システムトラブルにあたったが,何を見たらいいかわからない……そんな場合には,これらのポイントを参考にしてみてください表2~4)⁠

表2 まず最初にチェックしたいログファイル

ログファイル説明
dmesgコマンド最近,カーネルから出力されたログを確認する
/var/log/messagesファイルカーネルやアプリケーションから出力されたログが出力される
その他利用しているプログラムのログファイル,統計情報を確認するとよい

表3 OS側から問題調査を行うための基本コマンド(Linux)

時間,メモリの利用状況,スワップの発生状況をモニタする場合に便利
コマンド名説明
sarカーネルのカウンタ情報を時系列に表示する。過去24時間の負荷状況を把握する場合などに便利
topシステム上の上位プロセスをモニタリングできる。ソート機能も便利
vmstatメモリやプロセッサ稼働率などをモニタリングできる。ユーザプログラム/カーネルのCPU処理
iostatハードディスクやSSDなどのディスク稼働状況をモニタリングできる。性能問題の原因がストレージにあるかを切り分けるために利用する
mpstat各論理プロセッサの処理状況を確認する
dstatvmstat/iostatに代わるLinuxカーネルのモニタリングツール

表4 さらに細かな調査で役立つツール(Linux)

perf性能プロファイリングツール。プロセッサがどの処理(関数)に時間を費やしているか, などを確認できる
ftrace,trace-cmdLinuxカーネルのトレース機構と利用するためのツール
w+L各論理プロセッサで実行中のプロセスのバックトレースを出力
Software Design

本誌最新号をチェック!
Software Design 2017年11月号

2017年10月18日発売
B5判/176ページ
定価(本体1,220円+税)

  • 第1特集
    データ分析に効く
    SQL50本ノック
  • 第2特集
    なぜ,コンピュータは割り算が下手なのか!?
  • 一般記事
    Redash+SQL勉強会で業務改善!
    エンジニア任せにしないデータ分析の基盤作り
  • 一般記事
    ホワイトボックススイッチって何?
    ユーザがソフトウェアを自作する新しいスイッチの形

著者プロフィール

長谷川猛(はせがわたけし)

(株)SRAで7年間のシステム構築&提案を経験したのち,Fusion-ioのセールスエンジニアを経て,フリーランスエンジニアとして活動中。『LDAP Super Expert』(技術評論社)に寄稿したほか,『Xen 徹底入門』(翔泳社)および『萌え萌えうにっくす!UNIX ネットワーク管理ガイド』(毎日コミュニケーションズ)の共著者のひとりである。

スノーボード,ごまラーメン,飼い犬のミニチュアシュナウザー「ラピス君」が大好き。

バックナンバー

トラブルシューティングの極意―達人に訊く問題解決のヒント

バックナンバー一覧

コメント

コメントの記入