Web Service ♥ SSD Pathtraq  への  SSD  導入記 Cybozu Labs, Inc. Kazuho Oku
<ul><li>座学 </li></ul>
HDD  上でのデータベース運用 <ul><li>HDD  は遅い </li></ul><ul><ul><li>7200rpm × 60sec/min × 0.5 =  平均 240tps </li></ul></ul><ul><li>書き込み...
HDD パフォーマンスの上限予測 <ul><li>限界 tps ×  アクセス単位  =  上限スループット </li></ul><ul><ul><li>アクセス単位  (bytes/transaction)  の把握 </li></ul></...
合成ベンチマークツールの利用 <ul><li>アクセス単位がわかればベンチマーク可能 </li></ul><ul><ul><li>だよねということでベンチマークツールを作った </li></ul></ul><ul><ul><li>% ./ran...
<ul><li>実践 </li></ul>
Pathtraq  と全文検索 <ul><li>Pathtraq  というサービスを開発・運用中 </li></ul><ul><ul><li>リアルタイムウェブアクセス統計システム </li></ul></ul><ul><ul><li>約 1 ...
Pathtraq  と全文検索  (2) <ul><li>全文検索 DB  には  Tritonn  を使用 </li></ul><ul><ul><ul><li>http://qwik.jp/tritonn/ </li></ul></ul></...
移行可否の検討 <ul><li>平均アクセス単位の把握 </li></ul><ul><ul><li>USB  メモリに検索  DB  をコピー </li></ul></ul><ul><ul><li>USB  メモリを挿し直しては、クエリ実行を繰...
Intel X25-M  のベンチマーク <ul><li>16KB/transaction  で測定 </li></ul><ul><li>       単位: MB/sec.  注 : hdparm -w 0 </li></ul><ul><li...
というわけで <ul><li>移行完了 </li></ul>
<ul><li>問題と対策 </li></ul>
ある種の検索クエリが遅すぎる問題 <ul><li>クエリがたまって  DoS  化 </li></ul><ul><li>全文検索は、検索クエリによってデータへのアクセスパターンが変化 </li></ul><ul><ul><li>but,  検索...
ある種の検索クエリが遅すぎる問題  (2) <ul><li>暫定対策 :  検索アボート機能を追加 </li></ul><ul><ul><li>Tritonn, Senna  へのパッチ作成 </li></ul></ul><ul><ul><li...
ある種の検索クエリが遅すぎる問題  (3) <ul><li>本質的原因は英単語のエスカレーション </li></ul><ul><ul><li>Senna  はキーワードが完全一致で見つからない場合、部分一致検索を試みる </li></ul></...
更新ロック問題 <ul><li>問題 :  データ更新に時間がかかる </li></ul><ul><ul><li>その間検索できない </li></ul></ul><ul><li>対策 :  更新処理の細粒度化 </li></ul><ul><u...
更新ロック問題  (2) <ul><li>問題 :  データ更新に、まだ時間がかかる </li></ul><ul><ul><li>原因は  Mecab  の形態素解析 </li></ul></ul><ul><ul><li>つまり  SSD  じ...
その他の問題 <ul><li>リストア速度は  HDD >> SSD </li></ul><ul><ul><li>シーケンシャルライトが遅いため </li></ul></ul><ul><li>HDD  と  SSD  の混載はチューニングが面倒...
<ul><li>評価 </li></ul>
コストパフォーマンス <ul><li>DRAM 64GB  の場合 </li></ul><ul><ul><li>50 万円〜 100 万円 </li></ul></ul><ul><ul><li>もれなくおまけつき : CPU  と  HDD <...
DB on SSD  について <ul><li>アクセス単位が小さい場合にオススメ </li></ul><ul><li>キャッシュの削減が可能 </li></ul><ul><ul><li>DRAM, RAID カード , memcached <...
Senna on SSD  について <ul><li>こちらも実用レベル  ( になったと思う ) </li></ul><ul><ul><li>+ Pathtraq  での実績 </li></ul></ul><ul><ul><li>100 万ク...
Upcoming SlideShare
Loading in …5
×

Web Service on SSD

5,332 views
5,262 views

Published on

Principles and Paradigms of running web services on SSD

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,332
On SlideShare
0
From Embeds
0
Number of Embeds
1,398
Actions
Shares
0
Downloads
29
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Web Service on SSD

  1. 1. Web Service ♥ SSD Pathtraq への SSD 導入記 Cybozu Labs, Inc. Kazuho Oku
  2. 2. <ul><li>座学 </li></ul>
  3. 3. HDD 上でのデータベース運用 <ul><li>HDD は遅い </li></ul><ul><ul><li>7200rpm × 60sec/min × 0.5 = 平均 240tps </li></ul></ul><ul><li>書き込みバッファを活用 </li></ul><ul><ul><li>DBMS, OS, RAID カード , HDD の各レベル </li></ul></ul><ul><li>ランダムリードはバッファリング不可能 </li></ul><ul><ul><li>I/O トランザクションを減らすしかない </li></ul></ul><ul><li>メモリキャッシュへのヒット率が最重要 </li></ul><ul><ul><li>OS, RDBMS, memcached … </li></ul></ul>
  4. 4. HDD パフォーマンスの上限予測 <ul><li>限界 tps × アクセス単位 = 上限スループット </li></ul><ul><ul><li>アクセス単位 (bytes/transaction) の把握 </li></ul></ul><ul><ul><ul><li>OS レベル </li></ul></ul></ul><ul><ul><ul><ul><li>iostat -k 3600 して (kB_read/s+kB_wrtn/s)/tps </li></ul></ul></ul></ul><ul><ul><ul><li>MySQL レベル (InnoDB) </li></ul></ul></ul><ul><ul><ul><ul><li>show innodb statusG の File I/O </li></ul></ul></ul></ul><ul><ul><ul><ul><li>innodb_flush_method=O_DIRECT 前提 </li></ul></ul></ul></ul>
  5. 5. 合成ベンチマークツールの利用 <ul><li>アクセス単位がわかればベンチマーク可能 </li></ul><ul><ul><li>だよねということでベンチマークツールを作った </li></ul></ul><ul><ul><li>% ./randombench.cc -b 16 -c 1 -f 102400 -l 1000 </li></ul></ul><ul><ul><ul><li>-b: アクセス単位 (16KB) </li></ul></ul></ul><ul><ul><ul><li>-c: 並走度 (1) </li></ul></ul></ul><ul><ul><ul><li>-f: テストファイルサイズ (100MB) </li></ul></ul></ul><ul><ul><ul><li>-l: 試行回数 </li></ul></ul></ul><ul><li>http://labs. cybozu .co.jp/blog/kazuhoatwork/2008/10/benchmarking_ssd_for_mysql. php </li></ul>
  6. 6. <ul><li>実践 </li></ul>
  7. 7. Pathtraq と全文検索 <ul><li>Pathtraq というサービスを開発・運用中 </li></ul><ul><ul><li>リアルタイムウェブアクセス統計システム </li></ul></ul><ul><ul><li>約 1 億 URL のアクセス統計を保持 </li></ul></ul><ul><ul><li>ヒット数が多いページについては全文検索可能 </li></ul></ul><ul><li>全文検索は参照局所性が低い </li></ul><ul><ul><li>& クエリ実行時に大量のデータにアクセスする </li></ul></ul><ul><ul><li>一部だけキャッシュするという手が使いにくい </li></ul></ul>
  8. 8. Pathtraq と全文検索 (2) <ul><li>全文検索 DB には Tritonn を使用 </li></ul><ul><ul><ul><li>http://qwik.jp/tritonn/ </li></ul></ul></ul><ul><ul><li>データサイズ : 約 18GB </li></ul></ul><ul><ul><ul><li>+ 約 3GB (InnoDB) </li></ul></ul></ul><ul><li>移行前 </li></ul><ul><ul><li>Opteron 2218 (2.6GHz, Dual Core) x 2 </li></ul></ul><ul><ul><li>32GB メモリ + HDD </li></ul></ul><ul><li>移行後 </li></ul><ul><ul><li>Opteron 240 (1.4GHz, Single Core) </li></ul></ul><ul><ul><li>2GB メモリ + SSD </li></ul></ul>
  9. 9. 移行可否の検討 <ul><li>平均アクセス単位の把握 </li></ul><ul><ul><li>USB メモリに検索 DB をコピー </li></ul></ul><ul><ul><li>USB メモリを挿し直しては、クエリ実行を繰り返す </li></ul></ul><ul><ul><ul><li>ファイルキャッシュゼロ状態からのテストが簡単 </li></ul></ul></ul><ul><ul><li>iostat から平均アクセス単位を把握 </li></ul></ul><ul><ul><ul><li>約 16KB だった </li></ul></ul></ul><ul><ul><ul><li>-> アクセス単位が小さい= SSD 化検討の価値あり </li></ul></ul></ul><ul><li>SSD を購入しベンチマーク&テスト </li></ul>
  10. 10. Intel X25-M のベンチマーク <ul><li>16KB/transaction で測定 </li></ul><ul><li>       単位: MB/sec. 注 : hdparm -w 0 </li></ul><ul><li>http://labs.cybozu.co.jp/blog/kazuhoatwork/2008/10/benchmarking_ssd_for_mysql.php </li></ul>585% 11.2 1.91 Write 注 385% 46.4 12.0 Write 1440% 38.0 2.64 Read 比率 SSD HDD
  11. 11. というわけで <ul><li>移行完了 </li></ul>
  12. 12. <ul><li>問題と対策 </li></ul>
  13. 13. ある種の検索クエリが遅すぎる問題 <ul><li>クエリがたまって DoS 化 </li></ul><ul><li>全文検索は、検索クエリによってデータへのアクセスパターンが変化 </li></ul><ul><ul><li>but, 検索クエリの全量テストをしていなかった </li></ul></ul>
  14. 14. ある種の検索クエリが遅すぎる問題 (2) <ul><li>暫定対策 : 検索アボート機能を追加 </li></ul><ul><ul><li>Tritonn, Senna へのパッチ作成 </li></ul></ul><ul><ul><li>slow query を kill するデーモンを作成 </li></ul></ul><ul><li>http://labs.cybozu.co.jp/blog/kazuho/archives/2008/11/mysql_damage_control.php </li></ul>
  15. 15. ある種の検索クエリが遅すぎる問題 (3) <ul><li>本質的原因は英単語のエスカレーション </li></ul><ul><ul><li>Senna はキーワードが完全一致で見つからない場合、部分一致検索を試みる </li></ul></ul><ul><ul><li>キーワードが英単語の場合は不要のはず </li></ul></ul><ul><li>恒久的対策 </li></ul><ul><ul><li>エスカレーション可否をキーワード単位で指定可能に </li></ul></ul><ul><ul><li>Tritonn, Senna へパッチ作成 </li></ul></ul><ul><ul><li>ウェブアプリが発行するクエリのチューニング </li></ul></ul><ul><li>http://lists.sourceforge.jp/mailman/archives/senna-dev/2008-November/001067.html </li></ul>
  16. 16. 更新ロック問題 <ul><li>問題 : データ更新に時間がかかる </li></ul><ul><ul><li>その間検索できない </li></ul></ul><ul><li>対策 : 更新処理の細粒度化 </li></ul><ul><ul><li>検索 DB の更新バッチ処理の SQL 見直し </li></ul></ul>
  17. 17. 更新ロック問題 (2) <ul><li>問題 : データ更新に、まだ時間がかかる </li></ul><ul><ul><li>原因は Mecab の形態素解析 </li></ul></ul><ul><ul><li>つまり SSD じゃなく CPU のスケールダウンが原因 </li></ul></ul><ul><li>対策 : Senna のパッチ作成 </li></ul><ul><ul><li>一部完了、大部分未完 </li></ul></ul><ul><ul><li>Senna 単体むけの対策は可能だが </li></ul></ul><ul><ul><li>Tritonn (MyISAM) の更新ロックの問題が痛い </li></ul></ul><ul><ul><ul><li>INSERT による追記以外だとロック発生 </li></ul></ul></ul><ul><li>http://lists.sourceforge.jp/mailman/archives/senna-dev/2008-November/001074.html </li></ul>
  18. 18. その他の問題 <ul><li>リストア速度は HDD >> SSD </li></ul><ul><ul><li>シーケンシャルライトが遅いため </li></ul></ul><ul><li>HDD と SSD の混載はチューニングが面倒 </li></ul><ul><ul><li>OS のファイルキャッシュは LRU </li></ul></ul><ul><ul><ul><li>キャッシュミス時のペナルティの差を加味してくれない </li></ul></ul></ul>
  19. 19. <ul><li>評価 </li></ul>
  20. 20. コストパフォーマンス <ul><li>DRAM 64GB の場合 </li></ul><ul><ul><li>50 万円〜 100 万円 </li></ul></ul><ul><ul><li>もれなくおまけつき : CPU と HDD </li></ul></ul><ul><li>SSD 64GB クラスの場合 </li></ul><ul><ul><li>〜 10 万円 </li></ul></ul><ul><ul><li>まともなやつを買いましょう </li></ul></ul><ul><ul><li>1台のサーバに複数個接続可能 </li></ul></ul>
  21. 21. DB on SSD について <ul><li>アクセス単位が小さい場合にオススメ </li></ul><ul><li>キャッシュの削減が可能 </li></ul><ul><ul><li>DRAM, RAID カード , memcached </li></ul></ul><ul><li>スレーブを SSD 化すれば壊れても影響少 </li></ul>
  22. 22. Senna on SSD について <ul><li>こちらも実用レベル ( になったと思う ) </li></ul><ul><ul><li>+ Pathtraq での実績 </li></ul></ul><ul><ul><li>100 万クエリ / 日 程度までいけるんじゃないか </li></ul></ul><ul><ul><li>Senna コミッタになったから言うわけじゃないよ </li></ul></ul><ul><li>クエリのチューニングは必要 </li></ul><ul><li>>10GB の全文検索がサーバ1台で提供可 </li></ul><ul><ul><li>既存アプリへの全文検索機能追加が容易に </li></ul></ul><ul><ul><li>検索サービスへの新規参入障壁が大幅に低下 </li></ul></ul>

×