タグ

サーバに関するmdoiのブックマーク (5)

  • サーバのディスクの話

    sugipooh @sugipooh 日にRAIDという言葉が無いころからストレージ障害の近くに居る。 すぐにデータが消えるMO、動いているときに「こつん」とたたくと古い データを消しても平気に動くHDD、それを守るためのRAIDのいい加減さ。 どうしてストレージ障害が起きるか?根を知らない人が多すぎる。 sugipooh @sugipooh RAID5コントローラを市場で初めて多数売った今は無いMylexへ研修に 行かしてもらった。そのときRAID5でデータが無くなる条件を聞いた。 「簡単に飛ぶ(驚)」。その10年後 日の会社がその簡単に飛ぶ条件で 多量にRAIDを売っている。おかげでデータ復旧会社が繁盛している。 sugipooh @sugipooh 「簡単にデータが飛ぶ」RAID5でビジネスを辞めたが、その頃から市場では ビジネスが拡がってゆく。正直なビジネスは儲からない。 対

    サーバのディスクの話
  • livedoor Techブログ : nowaのサーバ構成

    こんにちはスエヒロです。 今回は弊社が提供しているブログサービス「nowa」(ノワ http://nowa.jp)の仕組みをサーバ構成を中心に紹介したいと思います。 nowaでは一般的なブログサービス要素とSNS要素の機能を実装しています。弊社には先行して提供している「livedoor Blog」、「フレパ」といった大規模なサービスがありますので、そちらの開発・運用で問題になった点などを参考にしつつ開発を進めています。具体的にはアクセスによる負荷への対策、データベースの分散化、画像のストレージング、冗長性、スケーラビリティといった点になります。 - ポータル(nowa.jp)、CMS(cms.nowa.jp) のサーバ構成 ポータルページ(nowa.jp)とCMSページ(cms.nowa.jp)は、静的なファイルのリクエストを捌く+動的なコンテンツへのリクエストをプロキシするフロントサーバ

  • はやいTCPサーバの書き方 - nyaxtのPC作業ログ

    cagra高速化にあたってのノウハウを一部公開してみます。また明日校正/更新します。つっこみ待ちです。 select(2)の代わりにepoll_wait(2), kqueue, /dev/epoll等を使う 他に山ほど解説ページがあるので略 大量のディスクリプタを処理するようなサーバの場合、多少効果があるかもしれません。しかし、クライアント数が少ない場合、劇的な性能の向上は見込めないとおもいます。クライアント数が多い場合は、1セッション1スレッドなモデルではOS側のタスクスイッチングのオーバーヘッドが効いてくることも多いです。クライアント数を増やすには複数のセッションを1スレッドで処理できるようにすると良いです。実装にあたっては、non-blocking ioを活用すると効果的です。 TCP_NODELAYを設定する Nagleアルゴリズムをオフにします。多少応答性が良くなります。 これっ

    はやいTCPサーバの書き方 - nyaxtのPC作業ログ
  • TheC10kProblem - 「C10K問題」(クライアント1万台問題)とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと

    TheC10kProblem - 「C10K問題」(クライアント1万台問題)とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと 目次 この文書について C10K 問題 関連サイト まず読むべき I/O フレームワーク I/O 戦略 1. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と レベル・トリガ型の完了通知を利用する. 伝統的な select() 伝統的な poll() /dev/poll kqueue() 2. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と 変更型の完了通知(readiness change notification)を利用する. kqueue() epoll リアルタイム・シグナル fd 単位のシグナル (Signal-per-fd)

    mdoi
    mdoi 2008/04/16
    C10K問題について
  • 速くて落ちないサービスを提供する - jkondoの日記

    外からはなかなか評価されない仕事としてもう一つ大きいのがサーバーの仕事です。はてなのように、1ヶ月のUU(ユニークユーザー)数900万人、月間のPV(ページビュー)が10億PVを超えるサイトを運営するには、当たり前ですが相当なサーバーやネットワークが必要となります。 これまでこのサーバーやネットワークについては、「なるべく安く」ということを目標に構築してきました。売り上げが安定的ではないため、業績が悪化した際にリスクとなる固定費をなるべく減らしたかったからです。(ちなみにはてなは外部からこれまで資を入れておらず、全て自分たちの事業で生み出した利益を元に設備投資を行ってきています。苦労して生み出した利益を使ってサーバーを買うわけですから、そのコストについて厳しくなるのは当然ですし、そのおかげでネットベンチャーには珍しく、完全自己資でここまで会社を成長させることができました。ただ、自己資

    速くて落ちないサービスを提供する - jkondoの日記
  • 1