MySQLでInnoDB、バランスを取り戻せ!
こんにちわ、kouです。
今日もMySQLのInnoDBにまつわる失敗談です。
1000万行を超える複数のテーブルに対して複雑なSQLを発行しデータを整形するバッチの稼働時間の遅延が大きな問題となっているシステムがありました。このバッチが一定時間に処理が終わらないと後続バッチに影響が出てしまうため、早急な対応が必要です。
その過程で経験した失敗を恥ずかしいのですが、書いてみました。
初日
このようなバッチ処理遅延に対して、複雑(=効率の悪い)SQLチューニングも並行して行いますが、対応に時間がかかるため、まずはOS、ミドルウェアのチューニングで対応できないか検討をはじめました。
多くの議論があると思いますが、
「ボトルネック調査は下のレイヤーから!」
をモットーとしているため、まずはハードウェア、OSレベルから調査をはじめます。
# 今回のバッチ処理はlocalhostで閉じてますので、ネットワークは調査対象から除外です。
vmstat、freeコマンドで調べたところ悩むことなくボトルネック発見。大量にスワップが発生してました。サーバにはメモリスロットがまだ空いてますので、「メモリを増やしましょう」ということで即決。幸い予備のメモリが4GBありましたのでサクッと増設完了。
バッチプログラムはSQL文を発行するだけですし、他にメモリを消費するプロセスもないことからinnodb_buffer_pool_sizeは増設分をそのまま豪華に割り当てます。
やれやれ、ということで初日の対応が終了。
| 物理メモリ | 4GB→8GB |
| innodb_buffer_pool_size | 2GB→6GB |
| スワップ使用量(swpd) | 約2GB |
日時: 2009年09月07日 19:40
| コメント (0) | トラックバック (0)
実践している読書術(2)
こんにちは、深田です。
さて、読書術のご紹介第2回です。(第一回はこちら)
- 本をどのように買うか・選ぶか
- どのようなタイミングで読んでいるか・そのための準備をどうしているか
- 1冊の本を読む際の読み方をどうしているか
読む準備をどのようにしているか
中身をどういうパートに分割しているか
中身の各パートをどういう順序で読むか
それぞれのパートをどういう読み方をしているか - 読んだ後どのようにしているか
の
1. 本をどのように買うか・選ぶか、からまず説明していこうと思います。
日時: 2009年09月17日 15:09
| コメント (0) | トラックバック (0)
« 2009年08月 |
2009年09月
| 2009年10月 »






