Something went wrong, but don’t fret — let’s give it another shot.
JavaScript is not available.
Something went wrong, but don’t fret — let’s give it another shot.
プロジェクト709-即興でサーバーを自作してみた - 怒涛のSyntax Error
Tweet ようやくこのプロジェクト709、自作サーバーフェーズまでやってきました。 私の一番好きなフェーズなのです。 ちょっと過去をおさらいさせてもらいますと、 以前、このような自作のラックマウント可能な1Uハーフサーバーをつくりました。 これはシャーシをゼロから自社で設計して金属加工会社にお願いしてつくったものです。 はてなさんのサーバーを強く意識したモデルで、幾度ものプロトタイプを経て完成した堅牢性の高いシャーシです。 この自作1Uハーフサーバーはいろいろこだわり部分がありました。 ・すべてのパーツを1U におさめるための厚さ検証。 ・シャーシのたわみを最小限に抑える薄くて丈夫な板金加工。 ・高熱にさらされても歪まない素材。 などなど... これらを実現していく上で、犠牲にしたのは多大な時間です。 時間を費やしたということは人件費を費やしたということです。 つまり、おおくのお金がかか
2010 the Year of MicroSlice Servers – Perspectives
Disclaimer: The opinions expressed here are my own and do not necessarily represent those of current or past employers. Recent CommentsMatt on Seagate HAMRJames Hamilton on Seagate HAMRMatt on Seagate HAMRJames Hamilton on Cost of Power in Large-Scale Data CentersChris K. on Cost of Power in Large-Scale Data CentersJames Hamilton on Cost of Power in Large-Scale Data CentersRob F on Cost of Power i
グーグルのサーバー数を図にするとこんな感じ
グーグルのサーバー数がものすごいことは有名ですが、それを図で表すと、こんなことになるらしいです。数でいうと100万台以上。 ただ、サーバーってみんな性能も違うし、バーチャルマシンはどうするんだとか考え出すとややこしいです。あくまで、ある基準で数えると他社と比較してこんなことになりますよ、というものとして見ていただければよいかと思います。 ちなみに、マイクロソフトは？ヤフーは？というと、各社データが古かったり非公開だったりの事情で、この図にはないのです。が、マイクロソフトは2008年半ば時点で21.8万台（推定）、ヤフー、アマゾン、イーベイ、GoDaddy、IBM、HP／EDSはそれぞれ5万台以上は持っているだろうとのこと。それらを全部合わせると、やっとグーグルと同じくらいになりそうですね。 （※なお、図中の文言について訂正です。iWebはアップルとはまったく関係ない｢ホスティングとITイン
来年度(2010年度)のRFPで主流となりそうなサーバ - blog.nomadscafe.jp
WEB+DB PRESS Vol.51の連載で、サーバRFPを設定してそれに基づいて購入していると書きましたが、来年度(2010年度)ぐらいのRFPになりそうな主流となるサーバを考えてみました。 まず、共通していること、前提など CPUのコア数はHTなどによる論理コア含む計算 ネットワークインターフェイスは1Gbpsを2つ以上。RX/TX MultiQueueをサポートしていること SSDはIntel X25-M 160GBもしくは同等製品 サーバは主に4タイプあります。 ■Utility Server 小規模DB、Q4MやGearmanなどのJobQueue/Workerサーバ、memcachedやSquid/Varnishなどのキャッシュサーバに利用するサーバ。目的に応じてHDDをSSDに換装して利用できることが必要となります。 CPU 8コア以上 * 1 Memory 16GB HD
ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない - kazuhoのメモ置き場
タイトルは煽り入ってますが。 仮に動的ページを生成するのにかかる時間が1秒、そのうちデータベースやmemcached等リモートサーバへの問い合わせ時間を除くいたCPUの処理時間が0.1秒とする。また、ピークのリクエスト処理量は、平均の２倍とする。 そうすると、クアッドコアのアプリケーションサーバで処理できるリクエストは、 4 core * 10 reqs/sec * 86,400 sec/day * 30 day/mon / 2 = 51,840,000 reqs/mon と、約5,000万PV/月を１台で捌けることになる。 CPUが動いている時間は全処理時間の10倍と仮定したわけだから、アプリケーションサーバの最大同時接続数は 4 core * 10 = 40 程度あればいいことになる。実際には、安全係数を２倍かけて 80 とか。リクエストの処理に必要なメモリ量を 100MB とすると、
自作って得なのかなと思って計算してみた (自作サーバカンファレンス感想) - kazuhoのメモ置き場
一昨日、自作サーバカンファレンスに参加してきました。とてもおもしろく色々刺激をうけました。はてなの田中さん楽天の方々始め、スピーカーの皆さんありがとうございました。ただ分からなかったのは、サーバを自作する必然性がどの程度あるのかな、という点でした。 確かに、発表者の方々が構築されているような、1CPU, 8GBメモリのような構成では、自作サーバには（少なくとも原価ベースでは）価格競争力があるようです。はてなさんは Core 2 Quad + 8GBメモリ + X25-M (SSD) で10万円という目安を提示してらっしゃいましたが、同等の構成をベンダーから購入するとなると、1.5〜2倍の価格になるのかな、と思います。例えばDELLのオンライン価格*1は以下のようになっています*2。 DELL PowerEdge R200 - \145,900- Xeon X3330 (2.66GHz, Q
自作サーバカンファレンス「はてなの自作サーバの実際」＋他セッション講演メモ - RX-7乗りの適当な日々
本日の自作サーバカンファレンス、申し込みして楽しみにしていたのですが、体調がよろしくなかったので泣く泣く不参加・・・にしようとしていたところ、なんと！Ust(USTREAM)配信されているようだったので、そっちで視聴しました。感謝！！ 1つ目のトークの"はてな"の自作サーバ事情の話、他各トークセッションのメモ書きを今後の自分のために残しておきます。 田中さん(id:stanaka)のオープニングセッション 自作サーバは安い早いうまい 必要十分な仕様 部品単位で調達・組立 独自のカスタマイズ(SSD使いたい、など) はてなでは1年くらいSSD使っている！ 安い Core2Quad + 8GB + SSD X25-M 80GB \100,000 + 5,000/month (1A) \160,000/year Amazon EC2と比べても、1年でもとが取れて、SSDも付いてくる 自作サーバの
ローカルポートを食いつぶしていた話 - download_takeshi’s diary
ここのところ、お仕事で管理しているシステムで、夜中に負荷が急上昇する事象が発生しており、夜な夜な対応に追われていました。 （このブログ書いている今も、負荷がじわじわ上昇中なんですが・・・） で、いろいろと調査した結果、ようやく糸口がわかってきました。 結論から言うと、ローカルポートなどのネットワーク資源を食いつぶしていたようです。 以下、調べていってわかったことなどのメモです。 トラブルの事象 運用しているのは Apache2.2 + mod_perl2 なwebサーバで、リスティング広告システムの配信系です。 リスティング広告の配信のシステムって一般的にロジックが複雑でいやーな感じなんですが、このシステムもご他聞に漏れずかなりのひねくれ者で、しかもトラヒックは結構多めです。システム全体で、日に1000万〜2000万クエリくらいかな。幸か不幸か、このご時勢においてもトラヒック的には成長し続
Google Suggestのようなものを高速に実現するサーバsuggested - グニャラくんのグニャグニャ備忘録@はてな
Google Suggestのようなものを高速に実現するサーバsuggestedというものを書いてみた。 が、しばらく放置していた。とりあえず公開してみる。 特徴 epollやkqueueを使っていてネットワーク部分が速い Sennaを使っていてSuggest部分が速い Sennaを使って正規化している。「トン」とか「ミリバール」(組み文字)とか「Ｗｉｋｉ」(全角)とかでも検索可能 置き場 CodeResosに置いてあります。 http://svn.coderepos.org/share/lang/c/suggested/trunk 一応、2008/01/17バージョンの全ソースコードを貼っておこう。 #include <sys/types.h> #include <sys/time.h> #include <stdlib.h> #include <err.h> #include <sys
Webサーバ書くのって流行りなの？ - グニャラくんのグニャグニャ備忘録@はてな
Memcachedの添え物として扱われている（ような気がする） libeventちゃんカワイソウ。 libevent というわけで、libeventとsennaを使って COOKIEによるセッション維持機能がついたWebサーバを書いてみた例。 (Sennaは単なるハッシュライブラリとして使っています。) mainを書き下すと、 Senna初期化 libevent初期化 httpd機能開始 URIごとにハンドラ関数を設定 イベントをガンガン処理 といった感じ。 Cでこれくらいの長さだったら、 妥当だと思います。 バグがありそうだし、セッション変数の種も適当だけど、 気にするなってことで。 実用にはならないけど、サンプルの１つとしてどうぞ。 LLな言語のインタプリタなんかを抱え込むと面白いのかもね。 #ifdef WIN32 #include <winsock2.h> #include <wi
HTTPプロトコルパーサのオーバーヘッドは18%以下という話 - kazuhoのメモ置き場
「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場に関するの具体的な話。 Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのかを書く際に自作したベンチマークツールがあるのですが、それを使ったベンチマーク結果をid:tokuhiromがhttp://d.hatena.ne.jp/tokuhirom/20091001/1254355956にまとめてくれている*1。それについて、ちょっと補足と実測値を。 まず、コメントにも書いたんだけど、サーバのスループットを測る際にはTCP接続を多重化する必要があるので、-a 100 -n 100 -f *2のようなオプションでベンチマークをとってください。あと、ローカルホスト上での測定か、ホスト間での測定か、によっても当然結果は変わる。 自分の環境 (linux 2.6.18-028sta
自分のサーバの性能を知っておく - tokuhirom's blog
http://github.com/kazuho/manymanythreads ↑kazuhoさんがCで書いたエコーサーバーと、そのベンチマークツールによって、自分のサーバでどんぐらいのQPSがでるのかがわかる。 たとえば自分のマシン(SC440)だと ./testechoclient -c 1 -n 1000000 -f -p 5050で、 77906.624081 reqs./sec. (1000000 in 12.835879 seconds)ぐらいでる。 一番単純なエコーサーバーをうごかしたときの性能を把握しておくことによって、どのぐらいの速度がでてしかるべきなのかが把握できるようになるという。 【追記】 ここで知った echo server の限界性能をもとに、その後、自分がなにかサーバ等を書いた場合に最適化したらどのぐらいの速度がでるかを予測できる(経験が必要だとおもうけど)
Kazuho@Cybozu Labs: Writing Hot-deployable servers (introduction of Server::Starter)
Yesterday at YAPC::Asia 2009, I did a LT introducing verious techniques to write hot-deployable servers, and introduced a perl module called Server::Starter that encapsulates the burden of developing support for hot-deployment within each TCP server program. The presentation slides are on Slideshare.
FCA TOPICS 株式会社はてな様 社内サーバ向け スイッチパネル製作
株式会社はてな様 社内運用１Ｕラックサーバー向け スイッチパネル製作 平成21年3月、弊社のお問い合わせフォームから一通の御連絡が入りました。 内容を拝見すると、「自社開発ツールに用いるプリント基板製造を対応出来ますか？」というお話。 得意分野というか、本業で有る内容の為、「対応可能です」と即時お答えを返信しました。 概要からの見積を多岐企業へのお問い合わせを行われた結果、ＦＣＡを委託先へ選定して頂いたとの事。 非常に光栄です。 お客様ご理解の下、製造に関する内容を当トピックスページとして公開させて頂く事に成りました。 お問い合わせ先は、人力検索 など 有益なツールを盛り込み、一風変わったポータルサイトを提供されている、 株式会社はてな の エンジニア 吉田様からでした。 はてな ポータルサイト 吉田様 blog ■対象とされるサーバー製品の説明と製造基板の目的■ タ
はてなサーバーを更に解剖 - 発言注意！
はてなの1U自作サーバーの情報が出てましたね。せっかくなので、写真からみてもう少しわかるところを掘り下げてみるとします。 1Uラックマウント可能なサーバを自作する - marqs blog 電源 電源は「Enhance FLEX 300」 最安値は、￥8,650くらい。300Wクラスの薄型電源では、最安クラスだと思うので、コスト重視ならいいチョイス。 冷却ファン(ケース取り付け用) ケース背面近くに２つある冷却ファンは「San Ace 40」っぽい。 取り付け位置とかも計算されてるんでしょうね。ラックの前面・背面の両方につけるので、非対称な位置につけることで、前後2台で空気循環させるような考え方かな？メモリやCPUを避けて、空気の流れを作りやすくしてるっぽい。 冷却ファン（CPU） 冷却ファン（CPU）は「Dynatron P199」 最安値￥3980ほど。丈が低いファンで他の選択肢が
1Uラックマウント可能なサーバを自作する - marqs blog
はてなでは以前から自社製サーバを使用しているのですが、今年の春に、新たに自社製1Uハーフサーバを開発しました。 最近、タワー型だとメーカー製でもかなり安価なサーバがあるのですが、データセンターでの運用を考えると1ラックへの集積度が問題になってくるので、必然的にラックマウント可能なサーバが求められます。1Uサーバの中で価格対性能比のよいものを探すと、まだまだはてな的に使いやすいサーバが少ないので、今回このような1Uラックマウント可能なサーバを自社開発しました。 さてこのサーバの特徴としては、 ケーブル類がフロントアクセス 組み立て簡単 いけてるインフラアルバイトのid:hxmasakiが組み立てると15分 1ラックに60台以上搭載可能 もちろん、電源容量との兼ね合いもあります ディスクのホットスワップが可能 低消費電力 お値段据え置き 以前の自社製サーバとほぼ同価格 といったところがあげられ
MessagePack + Wavy で高速なRPCサーバーを書く「ccf」 - Blog by Sadayuki Furuhashi
先日、追記型オブジェクトストレージKastorを紹介しました。そこで「C++でクラスタアプリケーションを書くためのフレームワーク（ccf; Cluster Communcation Framework）を実装中」などなど書きました。 最近C++でサーバープログラムを書くときには MessagePack（シリアライザ･デシリアライザ。プロトコルに利用）とmp::wavy（イベント駆動I/Oとスレッドプールを統合してうまく動かすライブラリ）という２つのライブラリを使うことが多い*1のですが、この2つを組み合わせるときにいつも似たようなコードを書いていたので、いっそまとめて1つのフレームワークのようにしたら便利そうだなーという動機でccfの開発を始めました。 …以下長々と書いていますが、論よりコード。このヘッダ と サーバーのサンプル と クライアントのサンプル を見れば、何ができるのかは大体分
はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ で id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、 接続のタイムアウト処理 ログの出力 メモリの確保や解放をやらない あたりにも気を配る必要がある、と思います。 接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件 に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。 ログの出力について、複数行を１回のシステムコールにまとめてもいいかど
Re はやいTCPサーバの書き方 - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ について、いくつか気になった点があったので。 Nagleアルゴリズムは、相手側のACK送信をまとめてくれるものです。これは、下記の様にアプリケーション側でパケットを意識した処理を行っている場合、邪魔になることがあります。 違うと思います。自分の理解では、Nagle アルゴリズムは、ACK を受信していないデータがある場合に、次のパケットを送信しない、というものです。RFC896 から引用すると、 The solution is to inhibit the sending of new TCP segments when new outgoing data arrives from the user if any previously transmitted data on the connection remains unackn
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
