前回の問題とはまた別件で、今度はbinlogのローテート切り替わりタイミングに更新クエリが停滞する、という問題を調べることになりました。調査の過程で何を誤ったか、Twitterという魔法陣から最強クラスの重鎮魔神を召喚してしまい、恐れ多くも原因の特定と対応方針の決定ができてヘコヘコな感じでございます。数十分に1回、更新クエリが停滞してアプリケーションにエラーログが残るということから、他のエンジニアが、どうもbinlogの切り替わり時にそれが起きているっぽいことを特定してくれました。発生時は1~3秒は更新機能が停止するので、結構なレベルの障害ということでした。write容量を見ていると、確かに切り替わり時に800~900MBの書き込みを確認できました。Flushされておらず、一気にFlushしていることが問題なのではないか、という方向性で調べていきました。2.3.1となかなか古めかしい環境ですが、この問題はioDrive2でも同様に起こっていました。それぞれにbinlogを置いて比較してみました。HDDでは5秒間隔でFlushされているっぽいのに対し、ioDriveでは一切Flushされない......binlogではなく、適当なログ追記プログラムで書き込んでも同様で、ioDriveではいつまで経ってもFlushされず、データはどうやって保全されているのか、ioDrive様はFlushしなくても秘密の場所に保全しているのか、Flushが見えないようにドライバが隠しているのか!とか、またioDriveを邪推する悪い癖が始まりました。5秒間隔のFlushは、pdflushによるもので、この辺が参考になります。無関係のように見えるので、この辺の挙動を無視しておくと危ない気がしたため、大先生にブーメランを投げてみました。ごめんなさい、twitter見ていませんでした。恐ろしいものの片鱗を味わったぜ...さすがFusionIO社のスペシャルテクニカルサポートは格が違った!Tweet質問からわずか2時間で現地に足を運ぶクォリティ!!皆さんもオンラインで質問をする時は『覚悟』を。『覚悟』をもって「質問したッ!」を使うよりも「質問してやるッ!」って言ってた方が幸せな時もあるかもしれません。大先生が無事ご到着なされ、早速、状況報告と原因究明の作業へ入りました。調べましたが、『ioDriveに定期的Flushがされない』問題の答えとしては、KernelとFilesystem、そしてioDriveドライバの相性問題によるものということになりました。2.3.1.123-1.0のうち、RedHat系のKernelは色々パッチが当たって、何が原因か追い難いという点と、この頃のioDriveドライバはまだまだ各種KernelやFilesystemとの問題が多く残っているので、3.x系の最近のものだと、かなり自信を持って対応できている、ということでした。I/O発生問題の解決方法ですが、2点あります。一括書き込みが発生すると想定した場合の、リスクを低減します。FlushのタイミングはOSに任せるというものです。これにより、今回は運悪くOSとioDriveの相性問題により、細かい間隔でFlushされず一括されるハメになりました。Flushしてくれるようになります。I/Oが重くなるという話題がされますが、そういう目的ではなく、OSの仕様に依存せず、MySQLのシステムとして明示的に数秒間隔でFlushするために、1以上に設定します。I/Oが発生することはなくなります。切り替えてみれば、大体どのように影響度が変わるかはわかります。普通に5秒間隔でFlushされたり、といった感じでした。最近の製品だと即座にFlushされ続けたりと、また別の挙動報告をいただけました。調整が安定的だと思います。他社エンジニアさんと取り組むのは非常に刺激になってよいですね。ご協力ありがとうございました。コメントをキャンセルメールアドレスが公開されることはありません。data-url="">外道父ドリコムで主にインフラエンジニアをやっている何でも屋。WordPress.。