tnmt.info

2010年：ぷらっとホーム，クラウド技術を応用した「スケールアウト型ストレージ」発売｜gihyo.jp … 技術評論社

2010年：ぷらっとホーム，クラウド技術を応用した「スケールアウト型ストレージ」発売｜gihyo.jp … 技術評論社ニュースリリースぷらっとホーム，クラウド技術を応用した「スケールアウト型ストレージ」発売2010年5月27日ストレージ, Key-Value-Store, クラウドコンピューティング, NASシステム, メタデータ, ストレージ, スケールアウト5月27日，ぷらっとホーム（株）は，スケールアウト型ストレージ「CloudStation dSS」（クラウドステーションディーエスエス）の販売を... kazeburo

Apache MPMをめぐる冒険 ～eventとpreforkを比べてみるよ～

Apache 2.3からMPMの切替が実行時(起動時)に設定ファイルから動的に選択できるようになる点について、以前当DSASブログ内の記事で紹介しました。このMPMの切替によってどのようなメリットを得られるのでしょうか。実際にこれを動かしてみたときのCPU使用率とネットワークI/Oの変化を見ながら、それぞれのMPMモジュールの性能・特性を比較してみたいと思います。 まずは実験です。以下のような環境を用意しました。クライアント側については、ab(Apache Bench)によって単一のURLをひたすらダウンロードする単純なものです。しかも静的ファイルなので(中身はダミー)、純粋にApacheの転送能力のみの比較になります。サーバには、CPUはAtom D510、メインメモリ4GBを用意しました。クライアントとサーバの間はGbEで繋がっており、同一セグメント(中間ノード無し)となっております。 対象となるダウンロードファイルは1kB、10kB、100kBの3種類とし、それぞれabにおけるリクエスト数の総数を下表のようにしました。 ファイルリクエスト数(-nオプション)同時接続数(-cオプション) 1k1000000100 10k1000000100 100k100000100 サーバ側ではpreforkとeventを切り替えて設定、こちらもそれぞれ下表のように設定しました。なお、MinSpareThreads/MaxSpareThreadsはMaxClientsと同値としました。プロセス／スレッド数の調整、生成および破棄によって生じる性能差を比較対象から外すためです。 MPMMaxClientsThreadsPerChild prefork64- event6416 Atom D510はLinuxカーネル上では4コアとして認識されます(デュアルコア、HyperThreading有)。これに合わせてevent MPMでは、MaxClientsの全体としてはpreforkと同値にしつつ、4コアを使いきるようにプロセス数を4としてスレッドはその中で分散するように設定しました。 さて、以上の環境でもって実験した結果、次のようなデータとなりました。一つずつ見て行きましょう。まずはGangliaで収集したCPU使用率とロードアベレージのグラフです。03:15の前と後でevent-1kとprefork-1k、続いて03:30の地点でevent-10k、03:35にprefork-10k、03:40にevent-100k、03:45の前にprefork-100kとなっています。 1kについては、ロードアベレージのグラフをご覧下さい。03:15の前後で差が出来ているのが分かるかと思います。1kという大変小さなファイルへのHTTPリクエストなので、preforkではリクエストが届くと同時にほぼ一気に全てのプロセスが活性化してロードアベレージおよび実行中プロセス数が急上昇しています。実行中プロセス数は、MaxClientsの上限値=64にほぼ張り付いています。一方で、event-1kの方ではあまり大きな上昇になっていません。これはそもそも処理の分散をプロセスではなくスレッドによって賄っているため、同時リクエスト数の上昇がプロセス数の上昇としては現れないようになっていることを表しています。 このように、1kファイルのテストではpreforkとeventそれぞれの特性をよく表していると言って良いのではないでしょうか。64プロセスを事前に立ち上げて用意しておくことにより、バースト時には全てのプロセスが一気に動こうとするprefork MPMと、プロセス数は抑制しつつ、スレッドで捌くことによって過負荷状態を避けるevent MPMと、はっきりと違いが現れています。 これが10kから100kへと移ってくると、次第にネットワーク転送の方が律速となってきて、実行中プロセス数の極端な上がりは無くなります。おそらくサーバの性能やネットワーク環境にもよるのでしょうが、preforkにおける負荷集中時の実行中プロセス数の急騰は、小サイズのファイルによって引き起こされる可能性が高いということになります。 次にabの結果です。それぞれ秒間リクエスト処理数、および全体転送バイト数です。 1k Download prefork: 4913.44…

NTT東日本が「モバイルWi-Fiルータ」をSIMフリーモデル込みで提供へ、無線LANサービスも大幅値下げ

NTTドコモが2010年夏モデル発表会において、無線LANに対応した音楽プレーヤーやパソコン、デジタルカメラ、ポータブルゲーム機、iPadなどで自社の回線を利用できるようになる「モバイルWi-Fiルータ」を発表しましたが、NTT東日本が同じモデルを「光ポータブル」として提供開始することが明らかになりました。 また、「光ポータブル」はSIMフリーモデルも提供されるため、イー・モバイルなどの回線でも利用できるほか、公衆無線LANサービス「フレッツ・スポット」の月額料金が大きく値下がりしています。 詳細は以下から。

Kyoto Cabinet 1.0.0リリース！

夏が近づくとウキウキしてくるmikioです。昨日ついにリリースされたKyoto Cabinet 1.0について今回は報告します。 1.0の位置づけ コミュニティ毎や製品毎にバージョン番号割り当ての方針は異なるわけですが、私の個人的なポリシーでは、1.0には特別な意味があります。すなわち、0.xのバージョンはbeta版的な位置づけで、「実サービスに使うのはちょっと待った方がいいですよ」ということを意味します。一方で、1.xはstable版的な位置づけで、「よろしければ実サービスでも使ってみてください」ということを意味します。私がstable版に設定する原則を以下に列挙します。 安定稼働を至上命題とする（バグがあればその修正を最優先する） APIを変更しない（変更するとしても後方互換性を維持する） DBファイルのフォーマットを変更しない（変更するとしても後方互換性を維持する） なるべく機能追加しない（追加するとしてもモジュールを分割して行う） テスト追加とリファクタリングと文書執筆は継続的に行う。 余剰工数でなるべくユーザサポートを行う。 安定性というのは永遠の課題ですので、1.0になったからってバグがないと言いきれるわけでもない（見つかったバグはもちろんすべて潰しているが、見つかっていないバグがもう無いということは証明できない）ので、あくまで気持ちの問題にすぎません。しかし、結構テストを書いたのでポピュラーな環境とユースケースでは普通に動くとは思います。 特徴のおさらい 1.0になった今や、Kyoto Cabinetは以下の特徴を備えます。いつの間にかWindowsがサポートされているあたりが激アツですね。 時間効率：ハッシュDBはO(1)、ツリーDBはO(logN)の時間計算量。更新能力は100万qps以上。 空間効率：レコードあたりのフットプリントが、ハッシュDBだと8～16バイト、ツリーDBだと2～4バイト。 並列性：ハッシュDBはレコード単位のread-write lockのみ、ツリーDBはツリーDBはページ単位のread-write lockのみ。 利便性：Visitorパターン風インターフェイスによるレコード操作の一般化。多相DBによるアルゴリズムの動的変更。 堅牢性：手動トランザクション、自動トランザクション、自動リカバリ等の実装。 移植性：UNIX系（Linux、FreeBSD、Solaris、Mac OS X）だけでなくWindows（VC++）もサポート。 他言語バインディング：C++がコアだが、C, Java、Python、Ruby、Perlのバインディングも提供。 Tokyo…

Hadoop で Wikipedia のテキスト処理を900倍高速化 - 生駒日記

Hadoop で Wikipedia のテキスト処理を900倍高速化 - 生駒日記今月中に実験の実装が終わるくらいでないと来月の投稿〆切に間に合わないので、今週から研究室のサーバに Hadoop をインストールしている。研究室にはサーバが20台弱あるのだが、そのうち10台強を使うことにして設定。これくらいの規模だと「大規模」と言うのは憚られるかもしれないが(Yahoo! や Google と比べて、という意味で。)、中規模、くらいには言ってもいいだろうし、たぶん、多くの大学や企...