- 2009-05-21 (木) 12:10
- メディアマーカー
たびたびのサービス停止で、
たいへんご迷惑をおかけしております。
サーバーが重くなる主要因は、
登録や編集などのデータ更新が集中すると、
データベースのテーブルがロックしてしまうためでした。
最近では、CNETなどで紹介いただいた結果、
新規ユーザーのメディア登録が集中してロックする、
という流れでした。
あまりに頻発するようになってきたので、
今回のメンテナンスとなりました。
現在、データベースには MySQL を利用しており、
ストレージエンジン MyISAM でテーブルを作成しています。
MySQLには別のストレージエンジン innoDB もあり、
比較すると以下のような特徴があります。
| 内容 | MyISAM | innoDB |
|---|---|---|
| ロック形式 | テーブル単位 | 行単位 |
| 平行性 | 低い | 高い |
| CPU負荷 | 低い | 高い |
| データサイズ | 小さい | 大きい |
| Read速度 | 速い | 遅い |
| 全文検索 | 可 | 不可 |
一般的には、参照が多いなら MyISAM、
ひんぱんに更新するなら innoDB と言われています。
これまで速度を重視して MyISAM を利用していましたが、
平行性の高い innoDB を試すのが今回のメンテナンス目的でした。
その結果は、
現在のサーバー環境では厳しいようです(^^ゞ
テストではCPU負荷が急増してしまい、
表示されるのに2倍以上の時間がかかってしまいました。
CPU性能が良かったりデータ量が少なければ、
また違った結果になったのかもしれませんが…。
多少の速度ダウンは仕方ないと思っていましたが、
あまりにも遅すぎてムリでした。
やっぱり、メディアマーカーは、サクサク動かないと！
次の対策として、
データベース用メモリ領域を約2倍することで対応しました。
メモリ上で高速処理すれば、
ある程度の集中なら耐えられるようになると思います。
そのぶん、メール処理などに影響があるかもしれませんが、
そのあたりなら許容範囲内でしょう。
次は、アクセス集中時に制限をかけたり、
ダウンしてもスグ復旧できるようにするなど、
バックアップ的な仕組みを検討したいと思います。
MyISAM から innoDBへ変換してテスト、
また元に戻して別の対策を行うなどした結果、
長時間のサービス停止となりました。
ご協力いただきありがとうございました。
今後もより良いサービスを目指して、
がんばっていきたいと思います。
- Newer: 第2回名古屋ライフハック研究会
- Older: ブログ戦略講座レポート
Trackbacks (Close):1
- pingback from クリックアシスト開発日記 - アクセス集中対策 09-05-30 (土) 22:12
-
[...] 先日のメンテナンス以降、 アクセス集中や大きなトラブルもなく安定しているようです。 [...]
