今後の負荷を RRDTool を使って予測してみよう
斎藤です。 今日は、RRDToolを使って、今後かかる負荷を手軽に予測する方法をご紹介します。あわせて、プログラムと連携して性能限界を越えそうなサーバがあるかを判定してみます。人手ではまかないきれない数のサーバに対して、一台ずつ問題の予兆を調べるときなどにお試しください。 ※CentOS 6.3 (64bit) + RRDTool の2013/2/20頃の最新ソースを用いて試しています 「限界」を早く知りたい！ ITインフラを運用している方の多くは、Cacti, Munin等で負荷を日々モニタリングされているかと思います。モニタリングしたデータを用いて今後を予測する際、どのようにされていらっしゃいますでしょうか？描かれたチャートの動きをもとに、経験と勘を駆使して「ヨイショ！」っとされている方も、いらっしゃるのではないでしょうか。 特に、ディスク容量やネットワークトラフィック等、根本的な対策
cron で > /dev/null して椅子を投げられないための3つの方法 - 酒日記 はてな支店
(タイトルは釣りです) いい加減、>/dev/null 2>&1と書くのをやめたらどうか - DQNEO起業日記 この記事のタイトルが twitter で流れてきたのを見て、「そうだ！出力を /dev/null に捨てるなんてとんでもないよね！」と思ってよく読んだら /dev/null に間違いなく捨てる方法だったのでつい crontabに > /dev/null 書いたら椅子投げる 2012-06-13 00:01:17 via YoruFukurou とつぶやいてしまったのですが、では出力を捨てないためにはどうすればいいのか。現時点での個人的ベストプラクティスを書き留めておきます。 デフォルト : メールで送る (MAILTO) せっかく cron daemon がログを捨てないためにわざわざメールで送ってくれるのに、それを > /dev/null で踏みにじるとはひどい。 とはいえ、
「バックエンドの経験はなかった」Instagram創業者は、どうやってシステムをスケールさせてきたか
昨日のPinterestの記事「Pinterestの急成長を支えてきたアーキテクチャとは？ Pythonで開発しAmazonクラウドで運用」に続いて、やはり写真を中心としたサービスで急成長してきたInstagramのスケーラビリティについて、まとめてみました。 InstagramもPinterestと同様に、基本はAmazonクラウド上でPythonとフレームワークのDjangoを使ったシステムを構築しています。興味深いのは、創業者の二人ともバックエンドの経験がないなかで試行錯誤をしてシステムをスケールさせてきた点です。 Instagramは先月、Facebookに買収されると発表されています。この先、Instagramのシステムはどう変わっていくのでしょうか。 Instagramのシステム構成 約半年前、昨年12月にInstagramのブログに投稿された記事「What Powers In
MySQLの監視はCacti+Percona Monitoring Pluginsがおすすめ(監視サーバ構築編)
MySQLの監視はCacti+Percona Monitoring Pluginsがおすすめ(監視サーバ構築編) 2012-05-18 MySQLをリソース監視する仕組みにはいくつかあるが、対象のMySQLサーバが5台以上ある場合はCactiがおすすめ。導入のしやすさだけでMuninを選ぶ人が多い気がするが、その選択基準は間違っている！ Cactiのいいとこわるいとこ 多数のグラフを見やすく並べられる muninと比べて多数のサーバから軽快に情報を収集・表示できる 監視対象には、MySQLのユーザを追加するだけでかなりの項目数を監視できる データの保存にデータベースが必須だったりしてセットアップがやや面倒 慣れるまで監視プラグインを書くのに手間取る Muninのいいとこわるいとこ 監視プラグインを書くのが簡単 監視サーバにデータベースなどが必要なく、セットアップが簡単 グラフの並び方などが
Pinterest のスケール
V 先生から教えて頂いたので、Instagram 同様 Django/AWS 構成の Pinterest のスケールをメモ。Pinterest はいつものアカウント名が初めて 先取 されたサービスなので、今後使わないと思います。 本題に入る前に、Python には The Zen of Python (日本語) という思想があります。私はこの思想を Python でのプログラミングだけでなく、インフラの構築の際も意識するように心がけています。"Simple is better than complex" です。Instagram や Pinterest のスケールを見て、この思想がもっと好きになりました。 Instagram はよりシンプルなインフラに更改していくことで、ただスケールするだけでなく、運用や変更のコストも最小限になるように最適化していると思います。結果的に Android ア
Instagram のスケール正攻法 -- Kosei Kitahara's Blog
Instagram がどこに買収されたとかは他のニュースサイトにお任せして、Django アプリケーションを正攻法でスケールして "成功" してるのがとても興味深いです。現時点で Instagram Engineering で紹介されていることと TechCrunch にも掲載されたスライドから個人的なメモとしてまとめてみました。 Instagram の哲学は シンプルであること オペレーション負荷を最小化すること すべて装備 とのこと。 Instagram は以下の OSS, サービスで構築されているようです。 >>> OS / ホスティング Ubuntu Linux 11.04 を Amazon EC2 にホスティング。以前のバージョンは高トラフィックになると固まる問題があったようです。運用は 3 人。EC2 にホスティングしている理由は、調査結果によるものではなく、"まだ進化途中だか
Zabbix2.0でJavaアプリケーションの監視
システム運用管理者にとって、安定したサービス提供のためには、管理機器の状況を監視することは非常に重要です。 現在、仮想化やクラウド化が進む環境では、管理機器の台数も膨大になり、できる限り効率良く管理する必要性が高まってきていると思いますが、このような状況を背景として、既存の監視ツールも、より仮想化やクラウド化に対応した形に進化しています。 本連載では、OSSの統合監視ツールの1つであるZabbixを取り上げ、先日リリースされた最新版2.0での新機能を中心に、より効率的に監視環境を構築・運用する方法についてご紹介したいと思います。 【連載目次】 第1回 Zabbix2.0でJavaアプリケーションの監視 第2回 運用コスト低減に有効なZabbix2.0新機能 第3回 Zabbix1.8から2.0への移行 第4回 ZabbixAPIを使って外部ツールとの連携 Zabbix2.0概要 Zabbi
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編）｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編） こんにちは、インフラ担当新人の nob です。 サーバー監視ツールで MySQL を監視しているのにデータが多すぎて活用していない。という方はいませんか？その豊富なデータをパフォーマンス・チューニングに活用しない手はありません。今回はサーバー監視ツールのグラフを読み解いた実戦経験を元に、「これだけ見れば大丈夫」というツボをまとめてみました。 これだけ見れば大丈夫！ クエリ編 ３つのつぼと５つのグラフ （その１）監視ツールが何を見ているのか知る （その２）監視のキモ、グラフ３点セット (Questions, Lock Waits と Transaction Handler) （その３）グラフでチェックする SQL チューニング ( Select Type と Handler) シンプルでお勧め、サーバー監視グラフ化ツール
AWS-CloudDesignPattern CDP2.0候補
AWSクラウドデザインパターンとは？ AWSクラウドデザインパターン (AWS Cloud Design Pattern, 略してCDPと呼ぶ)とは、AWSクラウドを使ったシステムアーキテクチャ設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を、分かりやすく分類して、ノウハウとして利用できるように整理したものである。 これまで多くのクラウドアーキテクト達が発見してきた、もしくは編み出しきた設計・運用のノウハウのうち、クラウド上で利用が可能なものをクラウドデザインのパターンという形式で一覧化し、暗黙知から形式知に変換したものであるといえる。 パターンの中には、クラウドでなくても実現できるもの、今まででも実現されていたものも含まれているが、クラウド上でも今まで通りのアーキテクチャが実現でき、かつクラウドを利用する事で、より安価にそしてより容易に実現できるものは、CDPとして収
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
プログラマならば使うべき：GitHubでDNS管理ができる Luadns | Everyday Deadlock
さきほどTwitterで流れてきたのでたまたま見つけたのですが、LuadnsというDNSホスティングサービスがかなり凄いです。Luaスクリプトでゾーン設定を書いてGitHubにpushするだけで即座にDNS設定ができてしまいます。 DNSホスティングサービスというと、多くの場合ブラウザを開いてログインしてコントロールパネルからポチポチと入力して送信して、、、という手順を踏まないと設定が更新できないわけですが、Luadnsは違います。example.com.lua ファイルをEmacsやVim(やその他エディタ)で開いてLuaスクリプトを書き、git commit ＆ git push で設定が完了してしまいます。push にフックして Luadns の設定が自動的に更新されます。 マウスまで手を動かすのが無限に遠く感じられるプログラマにとっては、これほど素早く簡単にDNSが設定できるのはか
ワンクリックデプロイ勉強会に参加してきた #ocdeploy - Diary of absj31
connpass-ワンクリックデプロイ勉強会 (資料公開)ワンクリックデプロイ勉強会 #ocdeploy | Ryuzee.com 2011/12/20 ワンクリックデプロイ勉強会 #ocdeploy - Togetter (写真：講演終盤、ワンクリックデプロイを実演中の@Ryuzee氏。) 開催までの経緯 まずはこちらのつぶやきやり取りを。 …という様な感じでつぶやきのやり取りがなされ、この日に晴れて『ワンクリックデプロイ勉強会』が開催されました。 開催場所は日本マイクロソフト品川本社。私自身この日が2回目のマイクロソフト本社での勉強会だったのですが、開始前のモニターには何とTV画面が。勉強会とは関係無いところでちょっとした驚きでした(笑) イベント発起人であるkatzchang(TwitterID:@katzchang)さんによる前説的トーク、会場をご提供頂いたTomoharu Nag
ソーシャルアプリのボトルネック調査例（strace編） : DSAS開発者の部屋
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の6日目です。 はじめに ソーシャルゲームの開発では、仕様変更への柔軟な対応が求められることが多い上、突発的なアクセス増加にも耐えられる応答性能が要求されます。 一昔前までは、サービスの性能を担保するにはきちんとアーキテクチャを設計し、入念に動作チェックして、負荷試験して、プロファイル取って・・・みたいなことをリリース前にひらすやるのが理想だと思っていた頃もありました。 しかし、ソーシャルゲームの世界ではリリース直後からイベントやキャンペーンなどの追加開発が入ったり、ユーザの動向やコミュニティを参考にして仕様を変更することが多いので、リリース前に頑張ってチューニングしていても、その性能を担保し続ける事が難しいといった現状があります。 まあ、これはこれで刺激があって楽しい面もありますし、遊んで
なぜ「DNSの浸透」は問題視されるのか:Geekなぺーじ
「DNSの浸透」という表現が結構よく使われています。 DNSに設定された情報を更新したけれど、その結果がなかなか反映されずに誰かに相談すると「DNSの浸透には時間がかかります」と説明されて納得してしまうという事例が多いようです。 しかし、うまく準備を行えば、実際の切り替え処理は、いつ完了するのかが不明な「DNSの浸透」を待つのではなく、事前に計画した時間通りに完了させることが可能です。 さらに、本来であればDNS情報の設定者(ゾーン情報の設定者)は、いつまでに世界中のキャッシュが更新されるかを知ることができる環境にあり、それ以降も更新がされていなければ「何かがおかしい」とわかるはずです。 DNSにおける設定内容(DNSのリソースレコード)には、その情報をキャッシュとして保持し続けても良い期間であるTTL(Time To Live)という要素がありますが、TTLはDNS情報設定者が自分で設定
perfの使いかた
概要 Linuxのパフォーマンス解析ツールであるperfの使いかたの紹介 背景 個人的にperfよくできてると思うので紹介したいというのと、 パフォーマンスカウンタの読み方ってあんまり知られてないみたいなので、 それの解説を書きたい。 構成 perf について説明したあと、パフォーマンスカウンタの読みかた、見かた、を説明する。 perfとは何か Linuxに付いてくるプロファイラ。 man perf によると、 NAME ---- perf - Performance analysis tools for Linux と、書いてある。名前がひどいのでなんとかしてほしい。 perf の特徴 個人的には、手軽に使えるのが素晴らしいと思う。 2.6.31以降カーネルに標準で付いてる。(Ubuntuだとlinux-tools-common(TODO:あとで確認)で入るはず) 特殊な設定が必要無く、
今こそ見直すApacheの設定 - blog.nomadscafe.jp
nginxやvarnishなどがアツいですが、Apacheもまだまだ実績や安定性から採用されていると思います。ここではデフォルトとは異なる値に変更するサーバ設定を中心に、パフォーマンス改善、安全性向上のためのApacheの設定を紹介します。 mpmの確認 > /path/to/bin/httpd -V Server version: Apache/2.2.19 (Unix) Server built: Jun 23 2011 17:13:13 Server's Module Magic Number: 20051115:28 Server loaded: APR 1.4.5, APR-Util 1.3.12 Compiled using: APR 1.4.5, APR-Util 1.3.12 Architecture: 64-bit Server MPM: Worker PreforkやW
sshを使いこなすための7つの設定 - 射撃しつつ前転 改
五月病が抜け切らないIT系新入社員に贈るシリーズ第1段。 ~/.ssh/configにはいろいろな設定が書けるが、周囲を見渡した限り、あまり活用されているようには見受けられない。そこで、今回は便利な設定をいくつか集めてみた。 長いホスト名に短い名前をつける Host exp1 HostName verrrryyy.looooong.hostname.example.jp ssh verrrryyy.looooong.hostname.example.jpの代わりにssh exp1でログインできるようになる。 ちなみに、zshの場合、configファイルに登録されたホスト名はsshコマンドを打つときに補完されるので更に便利。 特定のホストへログインするときのユーザ名や鍵をカスタマイズする Host github.com User tkng IdentityFile ~/.ssh/id_rsa
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://dl.dropbox.com/u/224433/fluentd_casual_1/index.html
fluentd を利用した大規模ウェブサービスのロギング
Av-jyo.com