oinume journal

Scratchpad of what I learned

Top > MySQL > hbstudy#5に参加してきました

hbstudy#5に参加してきました

MySQL

インフラエンジニアじゃないけどインフラエンジニア勉強会 hbstudy#5に参加してきました。もともとこのイベントには参加したいなぁと思っていて、参加登録したらいいタイミングで松信さんが講演することにw 貴重なMySQLのチューニングの話が生で聞けてとてもよかったよかった。

 

あと、最初にPostgreSQLの話をしていた永安さんのセッションもよかった。普通DBの入門の話ってあまりつっこんだ運用の話は出てこないと思うのですが、運用を意識した入門編でこういうのはすごい貴重だったのではないかと。

 

PostgreSQL安定運用のコツ2009

永安さんの話はスライドを見てもらえばほぼ全てわかります。スライドが充実し過ぎていてあまりメモを取っていなかったのですが、最近のポスグレはAuto Vacuumなんて仕組みがあって、あまりVacuumを意識しなくてよいのだなぁと。あとポスグレもチューニングはいかに共有バッファをうまく使うかっていうところで、あんまりMySQLと変わらないんだなって思いました。

 

Linux MySQLサーバーのパフォーマンスチューニング

資料(PDF)

MySQLのチューニングの基本はデータサイズを小さくしていかにメモリにのっけるか、という話。たとえば、日時を格納するカラムはDATETIME(8byte使用)じゃなくてTIMESTAMP(4byte)を使えとか。statusみたいな1/0しか入らないカラムは文字列型じゃなくてTINYINTかENUM使えとか。ちなみに日時は2038年問題が気にならないのであれば、UNIXTIME化してINT型のフィールドにしてしまうという荒技もありますよね。アプリケーション側でいちいち変換しなくてはいけないですが。

 

あと「巨大なTEXT/BLOBはクエリ効率を悪化させる」という話で、巨大なデータを格納するカラムは別テーブルにすると、それ以外のカラムのデータをSELECTするときに悪影響が出ないらしい。ちょっとどういう話か失念してしまったので、資料が公開されたら復習します。一定以上の大きさのテキストフィールドを別領域に保存するストレージエンジンとして、Falcon, PBXTがあるとのこと。ちなみに、HDDが一秒間に処理できるランダムI/Oはせいぜい数百ぐらいなので、とても遅いですと。

 

あとは実データを引かずにCovering Index(インデックスだけを読む検索)でうまく処理する方法もあるそうで、

 

 

  • テーブルのレコードにアクセスする必要がなくなるので、高速になる

 

 

  • Indexのサイズが大きくなるので、更新のコストが高くなる

 

 

  • Limit句を使うときにも効果がある

 

 

というメリットデメリットがあるそうです。

 

 

 

  • メモリを十分に確保してダイレクトI/Oを活用する

 

 

  • オンライン処理のあとに、バッチ処理で巨大なテーブルに対してフルスキャンするのは問題がある

 

 

  • バッチ処理によるバッファプールが占有され、オンラインのバッファプールが追い出されてしまうため

 

 

  • OOM Killerに注意する

 

 

  • ダイレクトI/Oを使うとプロセス内にデータが置かれるので、プロセスのサイズが大きくなる

 

 

 

 

  • # echo 0 > /proc/sys/vm/swappiness = 0

 

 

  • -> Direct I/Oとセットで使うことが多い

 

 

  • cpで大きいファイルをコピー

 

 

 

 

  • InnoDBのプロセスのデータがスワップに追い出される->これは避けたい

 

 

 

 

 

  • もっとも使われていて安全

 

 

  • dir_index, noatime(relatime)

 

 

  • xfsはDirect I/Oだと並列で書き込める

 

 

  • xfsは巨大なファイルのコピーがはやい

 

 

  • でもxfs使っている人少なすぎなので、おすすめできないｗ

 

 

 

 

  • 監視の方法

 

 

 

  • iotop: プロセス単位でI/O量を取る kernel 2.6.20以降

 

 

  • ネットワーク統計: MySQL Cluster使う人には必要かも

 

 

  • mtstat: 一秒おきに受信/送信byte数を表示

 

 

  • /proc/net/dev をみればわかる情報

 

 

 

 

 

 

 

 

 

  • 書き込み性能は製品による差が激しい

 

 

  • write cache必須

 

 

  • バッテリーで守れていることが重要。RAIDコントローラに任せるものとSSD自身で持つものがある(RAID Controllerの場合はそれがSSDに対応していることが重要)

 

 

  • SSDは並列性が重要。Crystalなんとかのベンチはシングルプロセスの話なのであてにならない

 

 

 

  • PCI-E型SSDにも注目 -> I/Fの速度が速い(300MB -> 2GB)

 

 

 

 

 

途中から殴り書きですが、TIMESTAMP型が4byteとDATETIMEの半分で済むことにこの日初めて知りました。その他Covering Indexなど、知らなかったテクニックなのでとても勉強になりました。あとSSDは本当もうすぐそこまで来ていて、これを入れるだけで数倍DBのI/Oが速くなることを考えるとすごいなぁと。しかし色々ベンチ取られていて、すごく説得力のあるお話でした。この人にコンサル頼んだらいくらかかるんだろう...