Linux環境におけるioDriveパフォーマンスの確認方法: Fusion-io
Linux環境におけるioDriveパフォーマンスの確認方法 パフォーマンスのテスト方法として以下をご紹介いたします。 kbを参照しながら実行される方が多いと思いますが、あくまでも本記事は翻訳版ですので 差異がある場合には原文を正としますので、補足資料としてご利用下さい。 また、注にもございますが、注意：下記で紹介するライト性能の測定方法は、ioDrive上のデータ（ファイルシステム）を破壊します。ioDriveを再度マウントするには、改めてファイルシステムを作成しなおす必要があります。 という点はご注意下さい。 パフォーマンス面をテストする方法としては実際の利用環境でHDDとioDriveでの実際アプリケーション、DBの実行速度を計測する事が一番近道だと思います。（バッチ処理時間before xxx時間→after yyy分とか） その場合のtipsは後日・・・下記文書をベースに作成 V
TPC-H Linux I/O Schedulreを変えてビックリ
引き続きTPC-Hの検証。 Linux I/O Schedulerには4種類ありますが、新久保君の TPC-Cの検証で Linux I/O Schedulerによるパフォーマンスの違いは無い という結果が出ています。 が、今回はおどろくべ結果が！！！ blocksizeLinux I/O SchedulerElapsedQphH@32GB 32KBcfq3,342 sec986 32KBnoop678 sec4,704 Linux I/O Schdulerを noopに変えただけで約5倍のパフォーマンスアップとなりました！ SSDの場合、ディスクヘッドのシークが無いので、何もスケジュールしない noopが有利だと言われていますが、こんなに異なるとは予想外。 リソース消費量についても処理時間を裏付ける結果となりました。 throughputは 133MB/secから 652MB/secへ。
SSDをめぐる議論に浮かび上がるベンダ模様（1/2） － ＠IT
8月版 SSDをめぐる議論に浮かび上がるベンダ模様 小崎資広 2009/9/8 お久しぶりです。先月は「セキュリティ＆プログラミングキャンプ2009」の準備があまりにも忙しくて、急きょお休みしてしまった筆者です。 8月は、2.6.31がリリース間近なこともあり、実験的なパッチの投稿は少なかったように思います。唯一、Jens Axboe（blockレイヤのメンテナ）による矢継ぎ早の超大型パッチの投稿が目立っていましたが、多くの開発者がサマーバケーション中なので、反応はイマイチ。そんな中、SSD周りの議論が強烈に面白い展開をみせていたので、大きく取り上げてみました。来月は、Jensパッチか2.6.31リリースの特集になる予定です。 それでは、どうぞ。 混迷深めるdiscardリクエスト ■全面書き直しが必要？ 8月15日、Nitin Guptaがswapサブシステムに新しい通知機構の追加を提案
OSSはアルミニウムの翼で飛ぶ: RHEL I/Oスケジューラの変更
RHELのI/Oスケジューラの変更方法。 環境によっては結構差が出てくるので、何がベストとは言い難い。 簡単にテストできるので環境に合わせて最適なスケジューラを設定しよう。 KVMではdeadlineスケジューラが推奨されている。 LinuxのブロックデバイスI/Oスケジューラはデバイス単位で指定されている。 現在の設定を確認するには、sysファイルシステム以下のblockを参照する。 # cat /sys/block/sda/queue/scheduler noop anticipatory deadline [cfq] こんな感じで出力されて、[]で囲まれているものが現在の値だ。RHELではcfqがデフォルト値となる。 この値は動的に変更可能で、変更するには設定したいスケジューラ文字列を上記のsysファイルシステムに書き込むだけ。 # echo deadline > /sys/bloc
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.velobit.com/storage-performance-blog/bid/126135/Effects-Of-Linux-IO-Scheduler-On-SSD-Performance
How to secure erase your hard drive (HD/SSD)