dstatの万能感がハンパない - （ひ）メモ
サーバーのリソースを見るにはグラフ化は重要ですが、推移ではなくリアルタイムな状況、例えば秒単位のスパイキーな負荷を見るには、サーバー上でvmstatやiostatなどの*statファミリーを叩く必要があります。 さて、vmstatはメモリの状況やブロック数単位のI/O状況は見られますが、バイト単位のI/O状況やネットワークの送信、受信バイト数を見ることはできません。 # vmstat 1 procs -----------memory---------- ---swap--- -----io----- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 3 1 0 4724956 355452 726532 0 0 54 484 3 3 1 0 99 0 0 2 0 0 47
Amazon ELBでホスト名なしのhttp://example.comを運用すると発生するいくつかの弊害 - （ひ）メモ
2011-05-25追記 ELBとRoute 53が協調動作するようになったみたいです。 New Route 53 and ELB features: IPv6, Zone Apex, WRR and more - All Things Distributed 【AWS発表】 クラウド上の名前解決サービスAmazon Route 53のベータをとり正式版に - Amazon Web Services ブログ まだ試してないんですが、www.example.comじゃなくてホスト名なしのexample.com (zone apexと呼ぶそうです)をRoute 53で管理すると、ELBのIPアドレスが変わったときに自動的にexample.comのAレコードが追従して変更される感じじゃないかと思います。スバラシス！！ →試してみたす Amazon Route 53＋ELBでホスト名なし(zone
Amazon EC2シンガポールを含む、ping RTTやhttpingの計測グラフ - （ひ）メモ
計測元は、都内のBフレッツでISPはライブドアプロバイダ。 計測とグラフ描写のコードはここに: http://github.com/hirose31/monitor-latency グラフは、紺色の線がレイテンシの平均値で、水色の範囲は最小値と最大値。 ping RTT まず、ホットなシンガポールのEC2。このグラフだけ、表示期間が1日分。だいたい90msecぐらいですね。 続いてEC2のwestとeast。この2つだけ、計測期間がちょっと古くて2010/3/27のもの。 Amazon EC2 アメリカ西海岸 125msec Amazon EC2 アメリカ東海岸 200msec あとはいろいろ。 ニフティクラウド Google JPIX はてなブックマーク 都内某iDC httping データは httping -c 10 -i 0.7 -r -g TARGET_URLの結果の最小値、平均
Eye-Fi用のアップローダブリッジ - Doumeki (百目鬼) - を作りました - （ひ）メモ
Eye-Fi用のアップローダブリッジを作りました。名前は Doumeki (百目鬼) といいます。 http://github.com/hirose31/doumeki/tree/master Doumeki を使うと、Eye-Fi からアップロードされた写真を複数のフォトストレージにアップロードすることができます。 図にするとこんな感じです。 動機 いまのところ、 Eye-Fi 単体でできることはこうなんですが: リモートのフォトストレージへのアップロード (ただし一か所だけ) Eye-Fi Managerが動いているパソコンへのアップロード Wi-FiのAd-Hoc接続した相手のパソコンへのアップロード (今のところ日本未発売のProのみ) 自分の場合、 複数のフォトストレージに同時にアップロードしたい でも、フォトストレージは一か所しか選べない LAN 内のファイルサーバにアップロー
Interop Tokyo 2009のクラウドコンにkumofsで出場します - （ひ）メモ
月曜からはじまったInterop Tokyo 2009ですが、6/11(木) 13:00からのクラウドコンピューティングコンペティション（略称：クラウドコン）に、古橋さん(id:viver)と一緒にチームえとらぼで出場します。 クラウドコンピューティングコンペティション（略称：クラウドコン） kumofsについての概略は、Key Value Store勉強会のときの彼の資料がありますのでこちらをどうぞ。 Key Value Store勉強会に行ってきました by kumofsのひと - 古橋貞之の日記 DHTとして、ノードが1つ2つ落ちたぐらいではサービスが停止しない・データが欠損しないというのはもちろんですが、kumofsは弊社で目下絶賛開発中のサービスのために開発されたプロダクトなので、「こういう動きの方が現場の運用がしやすい」という意見も取り込んで実装しています。この「運用しやすさ」
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
