sanonosa システム管理コラム集: サーバのボトルネックはどうやって調べるか
サーバのレスポンスが遅くなると経験のないサーバ管理者は無意味にメモリ増強を行ったりしますが、行き当たりばったりのシステム拡張は無駄な投資につながります。ボトルネック個所の調べ方は案外簡単なので、この際押さえるところをきちんと押さえて正しい方法論でシステム拡張をしていきましょう。 【一般論】 ボトルネックとなりうる要素は主に４つです。 ①CPU使用率 ②メモリ使用量 ③ディスクI/O ④TCPコネクション数 これらを押さえておけばボトルネック個所の把握とその解消は難しくありません。これを踏まえた一般論を述べてみたいと思います。 WEBサーバの場合は多くの場合、TCPコネクション数から先に限界が来ます。OSやApache等のWEBサーバのパフォーマンスチューニングを十分施すことが前提ですが、その場合TCPコネクション数1万くらいまではなんとか保てると思いますが、それ以上のTCPコネクショ
PureRubyなRTMP(MP4/H.264)サーバをオープンソース化しました - @takuma104 log
＃とりあえずオープンソースではMP4/H.264は一番乗りかな？ 先日の Re:RTMP(MP4/H.264)サーバをPure Rubyで書いた - @takuma104 log ですが，ソースコードを若干整形してオープンソース化しました。まだかなりテスト版な感じですが。名前ですが、あまり深く考えずにRubyIZUMIと名付けました。 Google Code Archive - Long-term storage for Google Code Project Hosting. subversionからチェックアウトするか、tarで持って来て展開かどちらかで。 使い方は，ほとんど先日のビデオと同じですが、若干コマンド名が違っていて、 $ ruby server.rb mp4file.mp4とかしてください。ブラウザでこのmp4を見るには、付属のplayer/Player.asをrascut
ウノウラボ Unoh Labs: UNIXデーモンを作ろう
20070405コードレビュー posted by (C)フォト蔵 尾藤正人です 先日ウノウの勉強会でUNIXデーモンの作り方についてプレゼンしました。 UNIXのデーモンの仕組みはWebサービスの開発にあたって直接関係の深いトピックではないかもしれませんが、知っておいて損はないと思います。 発表資料と動画を公開しますので、よかったらご覧下さい。 普段は気にしないUNIXデーモンが裏で何をやってるのか、少しでも身近に感じていただければと思います。 発表資料の公開にはちまたで話題のScribdを使ってみました。 プレゼン資料はKeynoteで作ったのですが、PowerPoint形式に変換してアップロードする簡単にできました。 デモ用に実際に動く簡単なデーモンプログラム ccho(シコー) を作成しました。 ccho は前々回の勉強会で行ったGnu Autotoolsで作った bat プログラ
ウノウラボ Unoh Labs: Rubyでネットワークサーバを書く
尾藤正人(a.k.a BTO)です 先日公開したブラウザだけでネットワーク対戦ゲームができるサイト「プラッシュ」では、 フラッシュとネットワーク通信を行う専用のXMLSocketサーバを開発しました。 このXMLSocketサーバはrubyで書かれています。 LLでデーモンを書く需要が、それほどあるとは思えませんが、デーモンを書く際に気をつけた点、工夫した点をまとめてみたいと思います。 なぜrubyを選んだのか rubyを選んだのには理由は2つあります。 Railsを採用した LLで早く開発をしたかった 僕も昨今のRailsブームにのって個人的にRailsを使い始めていました。 プラッシュは完全に新規プロジェクトで環境を選択する事ができたので、迷わずRailsを選択しました。 では、なぜCのようなコンパイル言語で書かなかったのか。 速く動くものを開発するよりも、早く開発をしたかったからです
とあるはてな社員の日記 - まっさらなサーバを30分で本番投入できるようにする
すこし前にはてなスターのリリースがされたのですが、サービス開始直後にありがちなことに、時々負荷で遅くなったり、アクセスしにくくなったりしてしまいました*1。これではいけない、ということで、すぐ次の日に、バックエンドのサーバを一気に10台近くまで増やして、おおむね快適に使える状態になっていると思います。この時に、新しいサーバをまっさらな状態から、だいたい30分程度で本番投入することができていました。これを、どのように実現したのかを軽く紹介したいと思います。 ちなみに、サービスの重さは、サーバ増強だけで済むものではなく、それ以降も、Javascriptが重い!とか、アプリケーションロジックで重いSQL を走らせてしまって遅いという問題は何回かありました。が、そこはインフラではなく、アプリケーションの問題で、アプリケーションの改善は、継続的に進んでいると思います。ので、今回は、インフラの話に限定
ウノウラボ Unoh Labs: WEBサービス運用における監視体制
こんにちは satoです WEBサービスは作るよりも運用の方がコストがかかるとも言われています。 運用を極力自動化して、コストを減らしたいものです。 ここではウノウで使っているツール類を紹介したいと思います。 1) 疎通、生存監視 webの生存監視などは nagiosを使って監視しています。 nagiosには - いつ(土日を除く、10時～22時までの間で など) - どのタイミングで(N回連続で ,復旧したら など) - 何が起こったった時に(疎通が取れない など) - どうするか(メールで通知する) などを細かく設定できる監視ツールです。 ウノウでは MySQL、memcached、HTTP、ping、DNS、SMTPなどの監視をnagiosで行っています。 2) システムやアプリケーションLOG ログの監視には swatch を使用しています swatchの機能には -
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://labs.cybozu.co.jp/blog/kazuho/archives/2008/03/fastr.php
