Web Service ♥ SSD Pathtraq への SSD 導入記 Cybozu Labs, Inc. Kazuho Oku

座学

座学

HDD 上でのデータベース運用 HDD は遅い 7200rpm × 60sec/min × 0.5 = 平均 240tps 書き込みバッファを活用 DBMS, OS, RAID カード , HDD の各レベル ランダムリードはバッファリング不可能 I/O トランザクションを減らすしかない メモリキャッシュへのヒット率が最重要 OS, RDBMS, memcached …

HDD は遅い

7200rpm × 60sec/min × 0.5 = 平均 240tps

書き込みバッファを活用

DBMS, OS, RAID カード , HDD の各レベル

ランダムリードはバッファリング不可能

I/O トランザクションを減らすしかない

メモリキャッシュへのヒット率が最重要

OS, RDBMS, memcached …

HDD パフォーマンスの上限予測 限界 tps × アクセス単位 = 上限スループット アクセス単位 (bytes/transaction) の把握 OS レベル iostat -k 3600 して (kB_read/s+kB_wrtn/s)/tps MySQL レベル (InnoDB) show innodb statusG の File I/O innodb_flush_method=O_DIRECT 前提

限界 tps × アクセス単位 = 上限スループット

アクセス単位 (bytes/transaction) の把握

OS レベル

iostat -k 3600 して (kB_read/s+kB_wrtn/s)/tps

MySQL レベル (InnoDB)

show innodb statusG の File I/O

innodb_flush_method=O_DIRECT 前提

合成ベンチマークツールの利用 アクセス単位がわかればベンチマーク可能 だよねということでベンチマークツールを作った % ./randombench.cc -b 16 -c 1 -f 102400 -l 1000 -b: アクセス単位 (16KB) -c: 並走度 (1) -f: テストファイルサイズ (100MB) -l: 試行回数 http://labs. cybozu .co.jp/blog/kazuhoatwork/2008/10/benchmarking_ssd_for_mysql. php

アクセス単位がわかればベンチマーク可能

だよねということでベンチマークツールを作った

% ./randombench.cc -b 16 -c 1 -f 102400 -l 1000

-b: アクセス単位 (16KB)

-c: 並走度 (1)

-f: テストファイルサイズ (100MB)

-l: 試行回数

http://labs. cybozu .co.jp/blog/kazuhoatwork/2008/10/benchmarking_ssd_for_mysql. php

実践

実践

Pathtraq と全文検索 Pathtraq というサービスを開発・運用中 リアルタイムウェブアクセス統計システム 約 1 億 URL のアクセス統計を保持 ヒット数が多いページについては全文検索可能 全文検索は参照局所性が低い & クエリ実行時に大量のデータにアクセスする 一部だけキャッシュするという手が使いにくい

Pathtraq というサービスを開発・運用中

リアルタイムウェブアクセス統計システム

約 1 億 URL のアクセス統計を保持

ヒット数が多いページについては全文検索可能

全文検索は参照局所性が低い

& クエリ実行時に大量のデータにアクセスする

一部だけキャッシュするという手が使いにくい

Pathtraq と全文検索 (2) 全文検索 DB には Tritonn を使用 http://qwik.jp/tritonn/ データサイズ : 約 18GB + 約 3GB (InnoDB) 移行前 Opteron 2218 (2.6GHz, Dual Core) x 2 32GB メモリ + HDD 移行後 Opteron 240 (1.4GHz, Single Core) 2GB メモリ + SSD

全文検索 DB には Tritonn を使用

http://qwik.jp/tritonn/

データサイズ : 約 18GB

+ 約 3GB (InnoDB)

移行前

Opteron 2218 (2.6GHz, Dual Core) x 2

32GB メモリ + HDD

移行後

Opteron 240 (1.4GHz, Single Core)

2GB メモリ + SSD

移行可否の検討 平均アクセス単位の把握 USB メモリに検索 DB をコピー USB メモリを挿し直しては、クエリ実行を繰り返す ファイルキャッシュゼロ状態からのテストが簡単 iostat から平均アクセス単位を把握 約 16KB だった -> アクセス単位が小さい＝ SSD 化検討の価値あり SSD を購入しベンチマーク＆テスト

平均アクセス単位の把握

USB メモリに検索 DB をコピー

USB メモリを挿し直しては、クエリ実行を繰り返す

ファイルキャッシュゼロ状態からのテストが簡単

iostat から平均アクセス単位を把握

約 16KB だった

-> アクセス単位が小さい＝ SSD 化検討の価値あり

SSD を購入しベンチマーク＆テスト

Intel X25-M のベンチマーク 16KB/transaction で測定 単位： MB/sec. 注 : hdparm -w 0 http://labs.cybozu.co.jp/blog/kazuhoatwork/2008/10/benchmarking_ssd_for_mysql.php 585% 11.2 1.91 Write 注 385% 46.4 12.0 Write 1440% 38.0 2.64 Read 比率 SSD HDD

16KB/transaction で測定

単位： MB/sec. 注 : hdparm -w 0

http://labs.cybozu.co.jp/blog/kazuhoatwork/2008/10/benchmarking_ssd_for_mysql.php

というわけで 移行完了

移行完了

問題と対策

問題と対策

ある種の検索クエリが遅すぎる問題 クエリがたまって DoS 化 全文検索は、検索クエリによってデータへのアクセスパターンが変化 but, 検索クエリの全量テストをしていなかった

クエリがたまって DoS 化

全文検索は、検索クエリによってデータへのアクセスパターンが変化

but, 検索クエリの全量テストをしていなかった

ある種の検索クエリが遅すぎる問題 (2) 暫定対策 : 検索アボート機能を追加 Tritonn, Senna へのパッチ作成 slow query を kill するデーモンを作成 http://labs.cybozu.co.jp/blog/kazuho/archives/2008/11/mysql_damage_control.php

暫定対策 : 検索アボート機能を追加

Tritonn, Senna へのパッチ作成

slow query を kill するデーモンを作成

http://labs.cybozu.co.jp/blog/kazuho/archives/2008/11/mysql_damage_control.php

ある種の検索クエリが遅すぎる問題 (3) 本質的原因は英単語のエスカレーション Senna はキーワードが完全一致で見つからない場合、部分一致検索を試みる キーワードが英単語の場合は不要のはず 恒久的対策 エスカレーション可否をキーワード単位で指定可能に Tritonn, Senna へパッチ作成 ウェブアプリが発行するクエリのチューニング http://lists.sourceforge.jp/mailman/archives/senna-dev/2008-November/001067.html

本質的原因は英単語のエスカレーション

Senna はキーワードが完全一致で見つからない場合、部分一致検索を試みる

キーワードが英単語の場合は不要のはず

恒久的対策

エスカレーション可否をキーワード単位で指定可能に

Tritonn, Senna へパッチ作成

ウェブアプリが発行するクエリのチューニング

http://lists.sourceforge.jp/mailman/archives/senna-dev/2008-November/001067.html

更新ロック問題 問題 : データ更新に時間がかかる その間検索できない 対策 : 更新処理の細粒度化 検索 DB の更新バッチ処理の SQL 見直し

問題 : データ更新に時間がかかる

その間検索できない

対策 : 更新処理の細粒度化

検索 DB の更新バッチ処理の SQL 見直し

更新ロック問題 (2) 問題 : データ更新に、まだ時間がかかる 原因は Mecab の形態素解析 つまり SSD じゃなく CPU のスケールダウンが原因 対策 : Senna のパッチ作成 一部完了、大部分未完 Senna 単体むけの対策は可能だが Tritonn (MyISAM) の更新ロックの問題が痛い INSERT による追記以外だとロック発生 http://lists.sourceforge.jp/mailman/archives/senna-dev/2008-November/001074.html

問題 : データ更新に、まだ時間がかかる

原因は Mecab の形態素解析

つまり SSD じゃなく CPU のスケールダウンが原因

対策 : Senna のパッチ作成

一部完了、大部分未完

Senna 単体むけの対策は可能だが

Tritonn (MyISAM) の更新ロックの問題が痛い

INSERT による追記以外だとロック発生

http://lists.sourceforge.jp/mailman/archives/senna-dev/2008-November/001074.html

その他の問題 リストア速度は HDD >> SSD シーケンシャルライトが遅いため HDD と SSD の混載はチューニングが面倒 OS のファイルキャッシュは LRU キャッシュミス時のペナルティの差を加味してくれない

リストア速度は HDD >> SSD

シーケンシャルライトが遅いため

HDD と SSD の混載はチューニングが面倒

OS のファイルキャッシュは LRU

キャッシュミス時のペナルティの差を加味してくれない

評価

評価

コストパフォーマンス DRAM 64GB の場合 50 万円〜 100 万円 もれなくおまけつき : CPU と HDD SSD 64GB クラスの場合 〜 10 万円 まともなやつを買いましょう １台のサーバに複数個接続可能

DRAM 64GB の場合

50 万円〜 100 万円

もれなくおまけつき : CPU と HDD

SSD 64GB クラスの場合

〜 10 万円

まともなやつを買いましょう

１台のサーバに複数個接続可能

DB on SSD について アクセス単位が小さい場合にオススメ キャッシュの削減が可能 DRAM, RAID カード , memcached スレーブを SSD 化すれば壊れても影響少

アクセス単位が小さい場合にオススメ

キャッシュの削減が可能

DRAM, RAID カード , memcached

スレーブを SSD 化すれば壊れても影響少

Senna on SSD について こちらも実用レベル ( になったと思う ) + Pathtraq での実績 100 万クエリ / 日 程度までいけるんじゃないか Senna コミッタになったから言うわけじゃないよ クエリのチューニングは必要 >10GB の全文検索がサーバ１台で提供可 既存アプリへの全文検索機能追加が容易に 検索サービスへの新規参入障壁が大幅に低下

こちらも実用レベル ( になったと思う )

+ Pathtraq での実績

100 万クエリ / 日 程度までいけるんじゃないか

Senna コミッタになったから言うわけじゃないよ

クエリのチューニングは必要

>10GB の全文検索がサーバ１台で提供可

既存アプリへの全文検索機能追加が容易に

検索サービスへの新規参入障壁が大幅に低下