5月27日、全日空（ANA）は大規模なシステム障害を引き起こした。システムの切り替えに起因するとされるが、ここから改めて分かることは、DRの基本、すなわちサーバ保護の重要性である。 5月27日、全日本空輸の搭乗手続き／手荷物管理で大規模なシステムトラブルが生じ、ほとんどの便が欠航となるという極めて大きな事故が生じた。自然災害によるものではないが、事業継続計画（BCP）という観点からは、ディザスタリカバリ（DR）の範ちゅうに含まれるとみることもできるだろう。 一部報道では、フェイルオーバークラスタの動作不良が疑われていた。システムの障害時に、不具合を生じたサーバから別のサーバに処理を移すことで処理を継続できるようになっていたのだが、何らかの原因でこの処理がうまくいかず、未処理のトランザクションがサーバ内に滞留したことが処理性能低下の原因ではないかという説である。現時点で真偽は不明だが、DRの
調べごとをしたので blog に書いて理解を深めようのコーナーです。長文です。 Linux でシステム負荷を見る場合にお世話になるのが top や sar (sysstat パッケージに同梱されてるコマンド) などのツールです。 top ではシステム統計のスナップショットを見ることができます。今システムがどういう状態かなーというときは top が便利。 top - 08:16:54 up 3 days, 14:43, 6 users, load average: 0.18, 0.07, 0.03 Tasks: 43 total, 2 running, 41 sleeping, 0 stopped, 0 zombie Cpu(s): 18.2% us, 0.0% sy, 0.0% ni, 81.8% id, 0.0% wa, 0.0% hi, 0.0% si一方の sar では10分ごとのシ
ようこそゲストさん ブログトップ 記事一覧 ログイン無料ブログ開設 d.hetima
このぐらいの規模のWebアプリケーションを作る場合、スクラッチからコードを書いていたのでは効率が悪いですし、また複数のプログラマで開発を進めるにあたってコードの品質を一定に保つのが難しくなってきます。ということで、ここはフレームワークの出番です。 PerlにはCatalystやSledge、CGI::Applicationといったオープンソースの優れたフレームワークがいろいろとありますが、はてなでは自社開発の「はてなフレームワーク」を利用しています。 はてなフレームワークを開発した当時の2001年頃はLL向けの良いフレームワークがあまり無かったため、自分たちで作りました。その後も改良を続け現在も同フレームワークを利用し続けています。 最近ではPerlに限らず、優れたフレームワークの実装が世の中に多数あり、その多くがフリーです。あまり自社開発のフレームワークを利用することの利点は多くないかも
無料レンタルサーバーを探しています。条件は以下の3点です。①CGIが使える。②容量が５MB以上ある。③登録内容が少なくて済むところ。（ID・メールアドレスなど）
サーバ異常をメールで知らせる統合監視ツール ～OpManagerでの監視～：ツールを使ってネットワーク管理（14）（1/5 ページ） げっ！Webサーバが落ちていると？ ユーザーの人たちがいろいろな面倒を引き起こしてくれるせいで、相変わらず大忙しの律子さんです。忙しさについ負けてしまって、特に問題も起きてないだろう、自動でアップデートしてるだろう、と前向きに考えて、すっかり日々のLANのメンテナンスがおざなりになってしまっています。人間楽な方に進んでいくものです。 そんなある日のこと。律子さんのところに、陽一さんがやって来ました。 洋一 「律子さん、うちの会社のWeb、見れないんだけど」 律子 「げっ」 洋一 「たまには見てやろうかと思ったら落ちてるんだよねえ」 律子さんの会社のWebサイトは会社案内くらいしかコンテンツがないのもあって、相変わらずアクセス数はほとんどないのですが、一応名刺
Perlで書かれており、RRD Toolと連携して、サーバに関するあらゆる情報をグラフ化し、HTMLを作ってくれます。MRTGよりも圧倒的にインストールも設定も簡単。グラフ化する対象はプラグインで簡単に拡張可能。 グラフ化できるのは、初期状態でディスク使用量・MySQL・IOstat・トラフィック・プロセス数・VMstat・CPU温度・CPU使用率・ロードアベレージ・メモリ使用率・スワップ・Netstat・HDD温度など。プラグインを追加することでさらにApacheのロードタイム・メールキュー・Asterisk・NFSクライアント・BIND・ColdFusion・DNSキャッシュ・MySQLの各種数値・PostgreSQL・印刷キュー・ProFTP・Qmail・電圧・S.M.A.R.T.・SpamAssassin・Tomcat・Tor・Windows Server・VMware・Xenなど
このサイトについて major PC section... AT互換機 PC-98x1 FM-TOWNS minor PC section... 8BitPC 16BitPC 32BitPC 68kFamilyPC other technical... 家庭用ゲーム機 携帯用ゲーム機 その他のコンピュータ CPU/コントローラ他 プロトコル/拡張子 アルゴリズム ライブラリ/API other section... ツール プログラミング言語 UI/フォント OS一覧 興味深い Information/Fun 書籍 Communication... けいじばん/一言 Resource... ScreenShot DiskImage Link... projects 関連サイト 最新の30件 トピック http://hotw
DSASのロードバランサは高価なアプライアンス製品ではなく、LinuxのLVS (Linux Virtual Server)を利用しています。 安価、というか、ハードウエア以外は金銭的コストがゼロなので、一般のクライアントからのアクセスを受ける外部ロードバランサのほかに、内部サービス用のロードバランサも配置しています。それぞれactive, backupで2台ずつあるので合計で4台もロードバランサがあることになります。(こんな構成を製品を使って組んだら数千万円すっとびますね) また、ネットワークブートでディスクレスな構成にしているので、ハードディスが壊れてロードバランサがダウンした、なんてこともありません。 ですので「ロードバランサは高くてなかなか導入できない」という話を耳にする度にLVSをお勧めしているのですが、どうも、 なんか難しそう ちゃんと動くか不安 性能が出ないんじゃないか 等々
データセンターの利用をいつ、どう判断するか：間違いだらけのデータセンター選択（1）（1/2 ページ） 企業が最適なITインフラを構築するために、データセンターをどう活用できるかを考える新連載の第1回目は、サーバを自社ではなくデータセンターで運用する判断に至るポイントについて説明する。 ITは社会のあらゆるところまで浸透し、企業活動にも欠かすことのできない存在となりました。しかし、ITインフラを安定的に運用することは困難を極めます。特に、自社でサーバやネットワークの管理をすべて実施することは、ネットワーク技術者の養成やネットワーク管理運用のためのコストなどを考えると相当な負担となり、セキュリティの面でも大きなリスクを負うことになります。 現在ではこうしたニーズを受けて、多くのデータセンターサービスが提供されており、これらをうまく組み合わせて使うことで、自社運用に比較して運用負荷やコストをかな
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Healthy Weight Loss Best Penny Stocks Cheap Air Tickets Credit Card Application Top Smart Phones Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy|Do Not Sell or Share My Personal Information
カリフォルニア州バーリンゲーム発--Googleの検索エンジンは大きな成功を収めているが、それを支える高度な技術は、ある疑う余地のない洞察をもとに考えられたものといえるかもしれない。その洞察とは「PCはクラッシュする」というものだ。 同社のエンジニアリング／運用担当バイスプレジデント、Urs Hoelzleは米国時間2日、Googleのデータセンターがどのように運営されているかについて、その一端を披露した。同社設立のきっかけになった実際の検索アルゴリズムよりも、同社が持つシステム運営上の知識のほうを高く評価する人は多い。 Hoelzleは、当地で開催されたEclipseConというアプリケーションプログラマー向けのイベントでこの講演を行った。 Googleは、比較的低価格のマシンを大量に購入することで、通常なら数千万ドルもかかるようなコンピュータインフラを、わずか数百万ドルで構築してしまっ
というわけで、再び負荷を下げる方法を模索した、戦いの記録。 1.MySQLの設定を変更して高速化 2.Zend Optimizer 3の導入 3.ionCube PHP Acceleratorの導入 4.テンプレートの見直しでクエリーを減らす 5.robots.txtでクロールする間隔を制御する 6.MySQLの設定を負荷を低くする設定に変更 7.キャッシュを有効化する 前回解説した「GIGAZINEのLoadAverageを「27」から「2」へ下げた方法」から約3週間後、6月20日（火）の夜、気がつくと負荷の15分平均は「25」をコンスタントに吐き出すようになり、さらに訪問者は急増、ついに6月28日（水）12時45分、負荷対策の効果がほとんど出ないまま、LoadAverage15分平均は「86」に…。 何か対策が根本的に間違っているのだろうか？それとも、もうGIGAZINEサーバのハード
最新文章 2018-12-26 17:10▪ 致敬英雄，致敬不朽的精魂 2018-12-26 17:10▪ 四十年来闵行人的文化生活史一幕幕回放 2018-12-26 17:10▪ “笔尖上的童画”——欢图学员作品成果展将在东方网文化活动... 2018-12-26 17:10▪ “金色热线”12月27日将迎来年终特别节目 2018-12-26 17:10▪ 北京市发布持续低温蓝色预警信号 2018-12-26 17:10▪ 北京市网信办推进自媒体账号专项治理关闭11万个 2018-12-26 17:10▪ 有创意的崇明“橘农”让梦想和情怀扎根农场 2018-12-26 17:10▪ 突发！上海地铁3、4号线晚高峰运行延误系人员进入线路 2018-12-26 17:10▪ 中国经济总量将达90万亿关键时刻传递重要信息 2018-12-26 17:10▪ 海底捞："吃出卫生巾"系人为当事顾客
なんつったって動画ですよ。 ブログとかmixi日記のようなテキストレベルのコンテンツに比べて、はるかにサーバーにかかる負荷は高いはずです。 YouTube と mixi を比較して "負荷" の話をしていて、「動画配信だから負荷が高い」と断定していますが、これは何を"負荷"とするかにもよるかなと思います。 "負荷" というと CPU load や I/O などリソースの消費っぷりを指す言葉というイメージがありますが。(一般的には違うものでしょうか?) そういう意味での負荷で言ったら、「YouTube = 動画 / mixi = テキストだから YouTube の方が負荷が高い」という断定はやや微妙です。負荷の種類が違うのです。 YouTube のシステムを見たときにその焦点になるのは、まず第一にネットワーク帯域。第二にストレージをどうしているかというところじゃないかなと思います。動画配信に
30万個ぐらいの静的ファイルを配信するサーバーの選び方 で静的な配信サーバに関することが述べられている. naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ（画像とか）を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 ということらしい.書いてあることはすべて同意だけど, つい3ヶ月くらい前まで 平均15k×1万URL×50億httpアクセス/day 平均4KByte×100万URL×3億HTTPアクセス/day な画像サーバと某所で向き合ってたため,ちょっとは役に立てるかもしれないと思ったので,私の経験を書いてみようと思う. 動画配信の負荷分
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
