以前、「噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた」でAmazon EC2で利用できるSSDボリュームのベンチマークを取った際に、EBSボリュームに関しても簡単に計測しているのですが、もう少し詳細に見てみようと思い、もうちょっと詳しく性能を計測してみました。(急いでいる方は最後のまとめを読むだけでOKですｗ) 実は、大昔(3〜4年くらい前)にも同じようなことを軽くやったのですが、結果がどこかにいってしまった＆今はまた結果が違うかもなので、やってみた。 ベンチマークの目的は、EBSボリュームをソフトウェアRAIDで束ねた(ストライピング)場合に、どのくらいパフォーマンスが出せるのかという観点。 というわけで、色々な観点から性能を測ってみました。使ったツールは「噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた -
環境 Ubuntu 12.04 Ruby-1.9.3 Rails-3.2 apache2 + Passenger この環境をすべてのクラウドに構築して、 ベンチマークをしてみました。 ベンチマーク用のRailsプロジェクトは https://github.com/xibbar/bench に置いておきました。 ベンチマークはapache benchを使って ab -n 400 -c 200 xxxx という感じです。 さくらVPS 2GB プラン 1480円/月 Requests per second: 80.61 [#/sec] (mean)PassengerMaxPoolSizeはデフォルト6なので、 これを16にしても劇的な変化なしです。 ちっちゃいRailsプロジェクトなので、 Passengerプロセスのサイズが50MBを切っているので、 16にしても2GBのプランで大丈夫でした
Nehalem Microarchitectureはメモリ速度については800MHz、1066MHz、1333MHzの３種類の中から選択できるので注意が必要です。 SPEC CFP2006で利用されている浮動小数点演算アプリケーションの一覧。 (公開されているSPEC CFP2006より転記しています。) bwaves (Fortran) : Computational Fluid Dynamics gamess (Fortran) : Quantum chemical computations milc (C) : Physics/Quantum Chromodynamics zeusmp (Fortran) : Physics/Magnetohydrodynamics gromacs (Fortran and C) : Chemistry/Molecular Dynamic
なんて幸運なことなんだろう。 実は最近、個人的にサーバーマシンを借りるという機会があった。そのマシンに搭載されているCPUコア数は合計48である！大事なのでもう一度いう。日本語でいう。48CPUコアだ！一昔前なら数千万円もしたスペックだろうが、最近は実にリーズナブルにお求めいただけるようである。（価格についてはふせておく。）このマシンには2.2GHzのOpteron 6174が4つ搭載されている。つまり、ひとつのパッケージに12個のコアが格納されているのだ。これはすごい。いや、むしろどうしてこうなった？！というべきか。そのようなマシンを目の前にすると時代はメニイコアに向かっているんだなあと実感せざるを得ない。 今後、CPUがどんどんメニイコアに向かう流れはさけれない。コアを増やさなければCPUの性能が（システム全体としての性能が）向上しないからだ。CPUの演算回路に対して半導体素子をたくさ
Filebench is a file system and storage benchmark that can generate both micro- and macro-workloads. It employs versatile Workload Model Language (WML) for detailed workload specification. Filebench includes several popular macro-workloads in its distribution: Web-server, Mail-server, Database-server, and others.
「多くのOLTPデータベースは30年前の設計を基にしており、今日の“Webスケールな”データベースの負荷を想定していない。これら伝統的なデータベースは、処理時間の90％以上がログ、ロック、ラッチ、バッファ制御といったオーバーヘッドに費やされ、しかもそれらによって限られた性能やスケーラビリティしか実現できていない」 Ingresの開発者でありInformixのCTOなどデータベースベンダの要職を歴任したデータベース研究者の大御所、マイケル・ストーンブレイカー氏が開発したVoltDBはプレスリリースでこのように既存のリレーショナルデータベースの欠点を示した上で、インメモリデータベースをベースにこれらのオーバーヘッドを除去し、ACIDによるデータ一貫性を維持しつつ大きな性能向上とスケーラビリティを実現したと説明されています。 SourceForge.jpの記事「「NoSQL」を上回る性能を目指す
データベース負荷テストツールまとめの第4回です。 データベース負荷テストツールまとめ(1) TPC-B、TPC-Wベースのツールを6つ紹介 データベース負荷テストツールまとめ(2) TPC-Cベースのツールを6つ紹介 データベース負荷テストツールまとめ(3) TPC-Hベースのツールを2つ紹介 今回はTPC-Eベースのツールを見ていきたいと思います。 TPC-Eとは TPC-EはRDBMSベンチマーク仕様の一つで、オンライントランザクション(OLTP)の性能を測定するものです。証券会社の業務をモデルとして取引や市場の監視、メンテナンス処理を行い、1秒あたりに行った取引件数を性能の指標値とします。 OLTPのベンチマークとしてはこれまでTPC-Cがよく用いられてきました。しかしTPC-Cは1992年の策定から実に18年が経過しており、その間コンピュータのCPU性能はムーアの法則にしたがって伸
データベース負荷テストツールまとめの第3回です。 データベース負荷テストツールまとめ(1) TPC-B、TPC-Wベースのツールを6つ紹介 データベース負荷テストツールまとめ(2) TPC-Cベースのツールを6つ紹介 かなり期間が空いてしまいましたが、今回はTPC-Hベースのツールを見ていきたいと思います。 TPC-Hとは TPC-HはRDBMSベンチマーク仕様の一つで、意思決定支援システム(DSS)としての性能を測定するものです。大規模なデータを対象にアドホックなクエリを実行します。クエリは全部で22種類定義されています。 TPC-HはTPC-B/W/Cなどと異なり、実行するクエリそのものやテストデータ生成ツールがTPCから提供されています。試しに、一番負荷が高い9番のクエリを確認してみましょう。 -- $ID$ -- TPC-H/TPC-R Product Type Profit Me
データベース負荷テストツールまとめの第2回です。 前回はTPC-Bベース、TPC-Wベースのものから6つのツールをご紹介しました。今回はTPC-Cベースのものについて見ていきたいと思います。 tpcc-mysql 対応RDBMS：MySQL 対応OS：Linuxなど 言語：C 作者：Percona Inc. ライセンス：不明(ライセンスに関する記述がない) トランザクション仕様：TPC-Cベース URL：https://code.launchpad.net/~percona-dev/perconatools/tpcc-mysql tpcc-mysqlはMySQLのコンサル会社であるPercona Inc.によって開発されたベンチマークツールで、TPC-Cをベースとしています。TPC-Cの仕様やtpcc-mysqlについては以前のエントリで詳しく扱っているので、そちらをご覧ください。 tpc
Webシステム開発において性能試験を行う場合、hp LoadRunnerやApache JMeterといったウェブブラウザをエミュレーションしてくれる負荷テストツールを用いるのが定番だと思います。そんななか、たまにデータベース単体での性能を測ってほしいと頼まれることがあるので、そうした便利なツールはあるのかなと思って調べてみました。 データベースに対する負荷テストツールは探すとたくさん出てくるのですが、案件で使用しているRDBMSに対応していなかったり、トランザクション仕様が希望と異なっていたり、微妙に作りが悪かったりと、ニーズに合致したツールはすぐには見つかりません。そんなときにこのエントリがツール探しの参考になればと思います。 pgbench 対応RDBMS：PostgreSQL 対応OS：Linuxなど 言語：C 作者：石井達夫氏 ライセンス：独自(BSDライセンスに近い) トランザ
Bonnie++はファイルシステムに関する様々なタスクをベンチマークすることができるツールで、RAIDの構成やファイルシステムの構成やネットワークファイルシステムの設定などを変更する際に大いに役立つ。 Bonnie++はopenSUSE 10.3（1-クリック・インストール）、Ubuntu Hardy、標準のFedora 9リポジトリなどから入手可能だ。今回は64ビット用Fedora 9リポジトリからインストールした。 Bonnie++はUbuntu用とFedora用のパッケージでは/usr/sbinにインストールされるのに対してopenSUSEでは/usr/binにインストールされる。ルートユーザとして起動するとエラーが出て実行できないのだが、/usr/binではなく/usr/sbinにインストールしてある場合、通常のユーザとして実行するためにはフルパスを指定する必要がおそらくあるだろう
コンピュータを構成する主要コンポーネントの中でも、ストレージ系のパフォーマンスは他に比べてかなり劣るものとなっており、例えばハードディスクは容量的には順調に拡大し続けているものの、そのアクセス速度の発展ペースはRAMやCPUの速度向上に追いつけなくなっている。こうしたハードドライブの性能的限界がシステムパフォーマンスのボトルネックとなっている可能性を考えた場合、各自の所有するディスクやファイルシステムが発揮可能な速度および、ディスクのサブシステムに対してユーザが行える設定変更の影響を数値的に把握しておくことは重要な意味を帯びているはずである。またディスクのアクセス速度を向上させる手法の1つとしては、RAID-5のように複数のディスクを組み合わせて運用することが考えられる。 Linuxの場合、物理ディスクに対するアクセス速度の基本的な情報であれば、hdparmツールに-Tおよび-tオプション
ネットワークのベンチマークでは、伝送速度と遅延時間という2つの指標が特に関心の対象となる。サービスや製品の広告では、伝送速度の方が大きく取り上げられることが多いが、状況によっては遅延時間の方が重要な指標となる場合もある。この記事では、ネットワークのパフォーマンス測定に利用できる3つのツールを見ていくことにしよう。nepim（network pipemeter）、LMbench、nuttcpの3つだ。 今回のテストでは、64ビットのFedora 9搭載マシンで各ツールをソースからビルドした。使用したバージョンは、nepimが0.51、LMbenchが3、nuttcpが5.5.5だ。 また今回は、ギガビット・イーサネットのネットワーク・インタフェース・カード2枚をbonding構成（翻訳記事）で組み合わせたネットワーク・リンクを使用した。だが、結果を見るとわかるように、何かがうまく機能していな
ファイルシステム比較 （ディスク容量使用効率編） システムの設計時にハードウェア構成のサイジングを行う際には、ファイルシステムの実効ディスク容量（＝ 物理ディスクの容量のうち実際に使用できる容量） を意識して、サーバの内蔵ディスクやディスクストレージのHDD構成を決定する必要があります。ファイルシステムには、ユーザが使用する実データを格納する領域以外に、メタデータやジャーナルログ等を格納する領域が必要になるためです。 このページでは、openSUSE 10.3 で選択可能な主要ファイルシステム（vfat等は除く）を対象に、 特別なオプション無しで mkfs を実行した直後の df 結果 1KB・10KB・100KB・1000KB のサイズでそれぞれ10000個のファイルを作成した後の df 結果 1MB （1024KB） ファイルの最大作成個数 を一覧にまとめていますので、参考にして
はじめに ext3ファイルシステムは、機能面・信頼性・性能面で非常にバランスの取れたファイルシステムであり、多数のディストリビューションで「標準のファイルシステム」として採用・サポートされてきました。現時点（2009年時点）では事実上、「Linux標準ファイルシステム」の地位を築いていると言っても過言ではありません。 しかしながら、「Linux標準ファイルシステム」のext3だけではなく、他ファイルシステムへの対応やサポートを売りにするディストリビューションも数多く登場しています。また、ext4やbtrfs等、次の「Linux標準ファイルシステム」と目されるファイルシステムも、現在、非常に活発に開発が進められています。 それでは、ext3から他のファイルシステムに乗り換える価値、他のファイルシステムを採用する価値はどの程度あるのでしょうか。 Linuxファイルシステムベンチマークの第2回は
Sebastian Bergmann has created the industry-leading testing tool PHPUnit, which has played a vital role in professionalizing software development with PHP. Sebastian shares his comprehensive experience in publications and at conferences. As Co-Founder and Principal Consultant of The PHP Consulting Company (thePHP.cc), he helps his clients to develop software successfully. In his free time, Sebasti
Created: Kazuki Ohta, 2006/06/14 Last Update: Kazuki Ohta, 2006/06/14 「write(2)の正しい使い方」と同じく、OS演習でやった事の延長線の記事を書いてみる。お題は「UNIX上で大規模ファイルを最速でコピーする方法」だ。一般的に、UNIXでファイルをcopyする際には以下のような方法が有る。 read -> write read -> write with posix_fadvice mmap -> mmap -> memcpy -> fsync mmap -> mmap -> memcpy -> fsync with madvise mmap -> write mmap -> write with madvise read, write, mmap辺りは良いとして、posix_fadviseというシステムコールが有
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く