Facebookのサーバーもすごいことになっている件（直近10ヶ月で20,000台のサーバーを追加。ログは毎日25TB。） - shibataismの日記
Googleに比べるととっても地味なPRしかしていないが、実はFacebookのエンジニアリングも結構すごい。CTOのJeff RothschildがUCSDで講演したビデオが見れるので今日がある方は是非見た方が良いと思います。 ビデオ http://cns.ucsd.edu/lecturearchive09.shtml#Roth http://video-jsoe.ucsd.edu/asx/JeffRothschildFacebook.asx 解説記事 http://www.datacenterknowledge.com/archives/2009/10/13/facebook-now-has-30000-servers/ ビデオを見たのが昨日なので、全部覚えていませんが、覚えていることだけでメモを書いておきます。全般的に、非常に素直な講演で、自分たちの良いところも悪いところも素直に言っ
スラッシュドット・ジャパン | サーバ監視、何使ってる？
SF.JP Magazineで「Webインタフェースでマシンを監視する4つの方法」という記事が掲載されています。Webインタフェースを持つ4つのサーバ監視ツール（collectd、Cacti、Monitorix、Munin）の特徴をそれぞれ解説した記事で、筆者は記事の末尾で以下のように述べています。 データをじっくりと分析する場合や、管理者以外のユーザからもシステムの統計情報を参照できるようにする場合は、最初にCactiをあたるのがよさそうだ。すでに十分な負荷がかかっているシステムで情報収集を行うなら、システムに与える影響の小さいcollectdを試せばよい。また、多数のノードで個別のアプリケーションパッケージを使って情報を集めるMuninは、同じようなマシンで構成される小規模なグループの監視に向いており、1台しかないサーバの状態を手っとり早く把握したければ、とりあえずCactiかMoni
DSASのファイル転送システムをオープンソースで公開します : DSAS開発者の部屋
DSASのファイル転送システムを、オープンソースで公開します。 その名は、makuosan（まくおさん：通称「まくお」）っていいます。 名前は冗談っぽいですが、内容はわりと真面目です(^^; MAKUOSANプロジェクトサイト Webサイトの運用に欠かせない作業のひとつに、「デプロイ」という作業があります。 これは、新しいプログラムやデータなどをWebサーバに設置して利用できるようにす ることを指していますが、サイトの規模が大きくなってWebサーバの台数が増えると、 それに比例してファイル転送にかかる時間も長くなっていきます。 一般的な話として、サイトの規模が大きくなるほど運用コストは増大しますが、 その要因のひとつとして「デプロイ時のファイル転送に時間がかかる」という 点がありました。そこで、できるだけ運用コストを抑える（作業者の負担を減 らす）ために、独自のファイル転送システムをこしら
GIGAZINE - GIGAZINEのLoadAvarageを「27」から「2」へ下げた方法
ここ3日間ぐらい超絶な重さだったのはサーバに物理的トラブルが発生したからではなく、単純に閲覧者数が満員御礼となり、各時間で倍増したためです。LoadAverageはひどいときで15分間の平均値「27.1」程度。瞬間最大風速だともっと高いです……明らかにまずい。 というわけで、Apacheのデフォルト設定で今までは大丈夫だったのですが、ついに高負荷サイト用の設定に変更せざるを得なくなりました。 そのため、実際に行った対処方法は以下の通り。1日30万PV近い動的サイトの高負荷を緩和させる方法として参考になれば幸いです。 まず大前提として、既にDNS逆引きや.htaccessの余計な読み込みなどは停止させていました。下記ページに書いてあることは実行済み。 ＠IT：Apacheパフォーマンス・チューニングの実践（1/2） この状態で負荷が15分平均で「27」になっていたわけです。 また、LoadA
cyano: 30万個ぐらいの静的ファイルを配信するサーバーの選び方
naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ（画像とか）を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 弊社の画像配信サーバーには、平均10kbぐらい（たぶん）の画像が30万個ぐらいあって、それをDell PowerEdge 1750+lighttpdを使って配信してます。 以前は搭載メモリ1GBのサーバーを使っていたのですが、その時のvmstatがこのような感じ。 procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b sw
サーバやPCのボトルネック箇所の簡単な見分け方(Linux編)：佐野裕のサーバ管理者日記：ITpro
前回はWindowsでのサーバやPCのボトルネック箇所の簡単な見分け方をご紹介させていただきましたが、要望がありましたので今回はLinuxの場合をご紹介いたします。 4つの主要ボトルネック要素の復習です。 サーバやPCには4つの主要ボトルネック要素があります。このいずれかがボトルネックとなった場合システム全体のレスポンスが低下します。 CPU使用率 メモリ使用量 ディスクI/O TCPコネクション数 Linuxにおいてはボトルネック箇所を以下のように見分けることができます。 1. CPU使用率 CPU使用率が常に100%に近い場合はCPUがボトルネックであることが判明します。CPU使用状況を簡単に調べるには3つの方法があります。「top」「w」「vmstat」コマンドを使う方法です。 -----------------------------------------------------
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自信を持ってApacheを操るために