Browse Month: December 2008

VMware Fusion のゲスト OS Linux Tips

VMware Fusion でゲスト OS として Linux の CentOS をインストールしたけれど、DHCP のためホスト OS から ssh するとき IP アドレスが分からないので困る。

そこで、ゲスト OS を固定 IP にしてみた。

まず、ホスト OS で DHCP のレンジを見るには、 “/Library/Application Support/VMware Fusion/vmnet8/dhcpd.conf” をみると分かる。僕の環境では、”range 172.16.123.128 172.16.123.254″ になっていた。ということで、ゲスト OS の IP アドレスを 172.16.123.127 にしてみることにした。

以下は、ゲスト OS での設定方法

  • /etc/resolv.conf の nameserver を 172.16.123.2 に変更する
  • eth0 のネットワーク設定 (/etc/sysconfig/network-scripts/ifcfg-eth0) を、BOOTPROTO を static に、IPADDRESS を 172.16.123.127 に変更する
  • /etc/sysconfig/network の GATEWAY を 172.16.123.2 に変更する
  • /etc/init.d/network restart して、設定を反映させる
あとは、ホスト OS の /etc/hosts に IP アドレスとホスト名を設定すれば、かなり便利になる。
これで、しばらく開発用途で使ってみると思う。

postgresql 8.3 on OSX

どうしても忘れてしまうので、MacPorts からインストールした portgresql で、EUC-JP なデータベースを作る方法。

  1. sudo chown postgres /opt/local/var/db/postgresql83
  2. sudo su postgres -c ‘/opt/local/lib/postgresql83/bin/initdb –no-locale -D /opt/local/var/d
  3. b/postgresql83/defaultdb’
  4. /opt/local/lib/postgresql83/bin/createuser -P -U postgres で、任意のユーザを作る
  5. /opt/local/lib/postgresql83/bin/createdb -h localhost -U postgres -E EUC_JP <データベース名>

ポイントは、–no-locale を指定するところ。

CentOS Tips – インストーラー編-

CentOS 5.2 x86_64 をセットアップしようとして、いくつかはまった。今後のためにメモをしておく。

  • グラフィカルインストーラーでないと、Software RAID 1 + LVM の環境をセットアップできない
  • cobbler でグラフィカルインストーラーにする方法は、Grapical Installs に書かれているがこの方法だとうまくいかなった、最新安定版の 1.4.0 だと /etc/cobbler/settings になるはずだけれど
  • そこで、VMware Fusion にインストールしようとしたところ、メモリが 256MB にすると anaconda がメモリ不足で落ちる(最低でも 512MB 以上設定すること)
  • CentOS をデフォルトでインストールすると、4GB はすぐに使いきってしまうので注意(10GB くらいはあったほうがいいかもしれない)

といろいろはまったけれど、ようやく CentOS をインストールして、Cobbler 1.4 で Software RAID 1 + LVM な kickstart インストールをできるようにする予定です。Cobbler の開発が激しく、機能も充実してきているのであとでエントリしたいと思う。

OSX にインストールするソフトウェアたち

年の瀬ということもあって、仕事マシンとして大活躍してくれた MacBook 白をいい機会なので再インストールした。再インストールしたら、今までのはなんだったというくらいに起動が速くなった。

OSX を再インストールしたあとは、仕事に必要なソフトウェアをいくつかインストールするついで、今日はそのソフトウェアたちを紹介します。

次に紹介するのは、実際にインストールした順番です。

  • teleport: 一言でいうと Synergy for OSX です、Synergy も OSX で動作すると思いますが teleport は OSX 専用でシステム設定から簡単に設定できるのが特徴
  • InsomniaX: OSX では MacBook を閉じると必ず Sleep 状態に入ってしまうが、InsomniaX を有効にすることでそれを解除することができる、22インチの外付けディスプレイを接続してミラーディスプレイ設定をして InsomniaX を有効にしてから MacBook を閉じてディスプレイの検出をすると MacBook 側の液晶はオフになって外付けディスプレイのサイズにあわせてくれるのでかなり便利、さらに teleport と組み合わせることで HHK や Logicool マウスを使えるのがかなり便利
  • iTerm: Terminal.app は 256 色対応していないので、重宝しているターミナルプログラム、アップデートがまだまだ激しいのでまだまだ開発が進んでいる、iTerm は開くデスクトップを固定して使っている、設定を外部に保存できないのが不便
  • Emacs: エディタ、OSX 向けには Carbon Emacs などいろいろな Emacs があるけれど、僕はほぼ公式の Emacs をビルドしたものを使っている理由は my .emacs が Carbon Emacs で動作せずに対応するのがめんどうだったから、定期的にアップデートされているのでチェックしたほうがいいかも
  • KeyRemap4MacBook: キーリピートは速くないと効率が悪いので重宝している、Initial Wait を 200ms、Wait を 20ms に設定している、最近のバージョンからタスクバーに表示されるようになった
  • MacUIM: ATOK を買う前に試してみましょう、Leopard でも動作します、Prime を使っていたけれどたまに重くなる傾向があったので今では Authy を使っています、トグルキーは Shift-Space を愛用しているので Spotlight のショートカットキーとかぶってしまうので無効にしている
  • Quicksilver: アプリケーションの起動やローカルにあるヘルプファイルの参照に使っている
  • SIMBL: これがないと始まらないです
  • visor: 基本的には iTerm だけれど、日本語の文字コードを設定を切り替えるのがめんどうなので Terminal.app だけ EUC-JP にしている、visor を使うとコマンド一発で起動できるので便利
  • TerminalCopyOnSelect: iTerm だとデフォルトで実現しているけれど、かんり便利なのでインストールしている
  • TerminalColoreopard: 個人的に ANSI カラーが見にくいのでインストールしている
  • iPhone SDK: Xcode 単体でもよいけれど、開発には必須
  • MacPorts: 仕事に必要な MySQL や PHP などをインストールするのに必須、ない場合は手軽に自分で作れるのも便利 … インストールする ports: zsh-devel, screen, SSHKeychain, mysql5-devel, postgresql83, apache2, php5, svk などなど
  • Ruby Enterprise Edition: rails アプリを開発しているので、passenger も自動的にインストールされて便利
  • macfuse, sshfs-static-leopard: SSHFS は超絶便利、まとめて sshfs でマウントできるように簡単な autometer アプリケーションを書いている
  • StartupSound: OSX の起動音を制御できるソフト、あの起動音はびびることが多いのでオフにしている
  • iStat menus: CPU、メモリなどの使用状況をリアルタイムにチェックできるプログラム

あとは、Firefox、Opera、Adium、Skype、OpenOffice の定番ソフトをインストールした。

MacPorts にある zsh にシェルを切り替えるには、/etc/shells に /opt/local/bin/zsh を追加して chsh -s /opt/local/bin/zsh で OK。

引き続き、Safari、Firefox のウェブ開発環境を整えるとする。

Windows の IE も必要だが、Corssover を試してみる。

sar の履歴保有期間を増やす方法

Linux で、過去の負荷などをチェックできる sysstat パッケージに含まれている sar コマンドで参照できる履歴保有期間を増やすには、sysstat の設定ファイルを書き換えるだけで対応できる。

CentOS 5.2 x86_64 の場合、 /etc/sysconfig/sysstat の HISTORY を次のように書き換えればいい。

# How long to keep log files (days), maximum is a month

HISTORY=28

デフォルトだと、最大1週間分しか保有されないので一ヶ月分にしておくと何かあったときに便利になる。なぜ、28 なのかは /usr/lib64/sa/sa2 のシェルスクリプトを見ると分かります。

CS193H

スタンフォード大学で、CS193H – High Performance Web Sites というタイトルの講義が行われた。そのときのプレゼンテーション資料が、公開されていた。講義は、9/22 から 12/5 まで行われて、おもに次のような内容だったようだ。講義タイトルを翻訳してみた。

  1. 9/22: 導入 – Introduction
  2. 9/24: フロントエンド側のパフォーマンスの重要性について – The Importance of Frontend Performance
  3. 9/26: HTTP ウェブサイトの 100 のパフォーマンスプロファイル – HTTP Web 100 Performance Profile
  4. 9/26: 開かれたウェブのパフォーマンス挑戦 – Performance Challenges for the Open Web
  5. 10/1: フロントエンドカンフー – Front End Kung Fu
  6. 10/3: 高いパフォーマンスのウェブページ – Netflix のケースで考える実例 – High Performance Web Pages – Real World Examples: Netflix Case Study
  7. 10/6: Alexa ランキングトップ 100 のウェブサイト – Class Project: Improving a Top 100 Web Site
  8. 10/8: HTTP リクエストを少なくする – Make Fewer HTTP Requests
  9. 10/10: CDN を使う – Use a Content Delivery Network
  10. 10/13: Expires ヘッダーを追加する – Add an Expires Header
  11. 10/15: Gzip コンポーネント – Gzip Components
  12. 10/17: 先頭にスタイルシートを配置する – Put Stylesheets at the Top
  13. 10/20: 末尾にスクリプトを配置する – Put Scripts at the Bottom
  14. 10/22: DNS 検索を減らす – Avoid CSS Expressions Reduce DNS Lookups
  15. 10/24: 外部に JavaScript と CSS を作る – Make JavaScript and CSS External
  16. 10/27: JavaScript を最小化する – Minify JavaScript
  17. 10/29: リダイレクトを無効にする – Avoid Redirects
  18. 10/31: 中間試験 – MIDTERM EXAM
  19. 11/3: Ajax のパフォーマンス – Ajax Performance
  20. 11/5: 重複している Script を削除する – Remove Duplicate Scripts
  21. 11/7: ETags の設定 – Configure ETags
  22. 11/10: Ajax をキャッシュされる&初期ロードを分割させる – Make Ajax Cacheable & Split the initial Payload
  23. 11/12: ブロックせずにスクリプトをロードする – Load Scripts Without Blocking
  24. 11/14: インラインスクリプトをばら撒かない – Don’t Scatter Inline Scripts
  25. 11/17: 大規模環境での高速なデータのスケール – Facebook から学ぶ – Fast Data at Massive Scale – lessons learned at Facebook
  26. 11/19: 主要なドメインを共有する – Shared Dominant Domains
  27. 11/21: イメージの最適化、Iframe を控えめに使う、ドキュメントを早めにフラッシュする – Optimize Images, Use Iframes Sparingly, Flush the Document Early
  28. 12/1: クッキーを自由にして固定リソースを出す、クッキーの重みを減らす – Serve Static Resouces Cookie-Free, Reduce Cookie Weight, To WWW or not to WWW
  29. 12/3: CSS 子孫セレクタで、圧縮を強制する – CSS Descendant Selectors, Forces Compression
  30. 12/5: パフォーマンスの状態 – State of Performance
  31. 12/9: 最終試験 – FINAL EXAM
  32. 12/12: 最終試験 – FINAL EXAM

ということで、Yahoo! から公開されている有名なウェブサイトのパフォーマンス Tips を含めた各テクニックを1つの講義で行ったり、実例から学んだりと、とても面白そうな講義になっている。それぞれの講義には、必ず宿題があったり、試験も公開されていて、かなり興味深い。

資料はほとんど公開されているけれど、数が多いので自分の興味のあるものをみてみるといいと思う。

僕は、とりあえずすべての資料に目を通してみたので、講義ごとにメモしておこう。

Intoroduction では、Yahoo! から Google に移籍した「ハイパフォーマンスWebサイト」の著者でもある Steve Sounders 氏の講義。ハイパフォーマンスの 14 のルール、Y! Slow などを紹介している。

The Importance of Frontend Performance では、iGoogle を例にあげて 8 割から 9 割のエンドユーザへの応答時間は、フロントエンド側で費やされていることをあげて、HTTPWatch という Windows 専用のパケットスニッファ、FirebugsY Slow を紹介している。

HTTP Web 100 Performance Profile では、HTTP の基礎的な解説のみで、宿題が5つのウェブサイトについて Y Slow などでパフォーマンスを計測するというもの。そのときのシートも公開されている。

Performance Challnges for the Open Web では、Plaxo でやっている OpenID や Google Social Graph API や OpenSociel などについての解説。これはゲスト講義だったようだ。

High Performacne Web Pages – Real World Examples: Netflix Case Study では、Netflix という実際のウェブサイトでのパフォーマンスを向上させたときの事例が解説されている。Firebugs にクライアント側のパフォーマンスデータを計測するプラグインがあることは初めて知った。

roundtrip-firebug.png (by billwscott)

さらに Jiffy Firebug の拡張を使うと、onLoad の時間などより詳しい計測ができるようになるらしい。

43 ページ目の Gzip 圧縮、Expire ヘッダーの追加、Etags を設定したことによってネットワークトラフィックが約半分になったという結果はとても興味深い。

Class Project: Improving a Top 100 Web Site では、これまでの講義を振り返りつつ、Alexa ランキングトップ 100 のパフォーマンスを改良するクラスプロジェクトを行ったらしい。

Make Fewer HTTP Requests では、HTTP リクエストを減らすために CSS sprites、base64 でエンコードしたインラインイメージデータ、のテクニックが解説されている。

Use a Content Delivery Network では、リバースプロキシとして CDN を使うことについて解説されている。

Add an Expires Header では、Expires ヘッダーを追加することについて解説されている。Expires ヘッダーを使うと、ブラウザ側にキャッシュを持たせることができるので、HTTP リクエストを減らすことにつながるのは既知のとおり。

個人的な体験では、Expires ヘッダーをはじめて追加したとき、それほど大規模サイトではないのでいきなり長い期間を設定してしまって大きな失敗をしたことがある。特に Expires ヘッダーを後から追加するときは、短い期間(たとえば1時間など)からゆっくりと設定しながら伸ばしていくのがいいと思う。

Gzip Components では、Gzip 圧縮について解説されている。Gzip と Deflate の比較表は、とても参考になった。若干 Gzip の方は圧縮率が高い。1K 未満のリソースは圧縮しないほうがいいらしい。トップサイトでは、ほぼ Gzip 圧縮されている。Gzip 圧縮はいいことだけど、古い一部のブラウザ IE 5.5 & 6.0、Netscape 3.x & 4.x では問題があるので注意して、BrowerMatch は設定した方がいいとのこと。これは忘れがちなので要注意。Apache 2.0 では、次のように設定する。

# BrowserMatch ^MSIE [6-9] gzip
# BrowserMatch ^Mozilla/[5-9] gzip

Put Stylesheets at the Top では、CSS を先頭におくことで体験速度が上がる。実際に、IE や Firefox で計測した例が紹介されている。

Put Scripts at the Bottom では、スクリプトブロックについて解説されている。ブラウザごとの挙動や、IE8 & Safari 4 & Firefox 3.1 & Chrome では並列にスクリプトをロードすることができるようになるらしい。それでも、IE6 & 7 はしばらくの間使われ続けるはずなので、「put scripts at the bottom」を心に刻めということ。

Avoid CSS Expressions Reduce DNS Lookups では、Steve 氏の講義で CSS の表記によってはページをダウンロードするのが遅くなること、DNS による検索を減らすルールについて解説されている。トップサイトの TTL は、ほとんど 1 分など短く指定している。ブラウザの DNS キャッシュは IE7 では 30 分、Firefox 2 では 1 分であるらしい。

Make JavaScript and CSS External では、JavaScript と CSS は inline としてページ内で定義するのがいいのか、それとも external として外部で定義するのがいいかについて解説されている。

  • inline: 高速だが、HTML ドキュメントが大きくなる
  • external: HTTP のリクエスト数が増えるが、キャッシュされる

ということで external がほとんどの場合よさそうということ。

Minify JavaScript では、JavaScript のコードからスペースなど余計な文字を除去して転送するデータ量を少なくする方法が解説されている。JSMinYUI CompressorDoJo Compressor を使うことで簡単に圧縮できるとのこと。トップサイトを調べた結果、約2割くらい転送するデータ量を削減できているとのこと。

Avoid Redirects では、リダイレクトについて解説されている。ヘッダーではなく、HTML ドキュメントの中にリダイレクトを挿入することはスクリプトでリダイレクトすることはよくないとのこと。HTTP ステータスコード 301 だとキャッシュされないが、一部のブラウザでは Expires を設定することがキャッシュされる。

Ajax Performance では、Ajax にまとをしぼったパフォーマンス向上 Tips について解説されている。

Remove Duplicate Scripts では、重複したスクリプトの除去として、aol.com では adsonar.jp が 6 回ロードされていることが紹介されて、Steve 氏のサイトでは同じスクリプトを 10 回ロードされるページが公開されている。

Configure ETags では、ETags の設定方法について解説されている。

Make Ajax Cacheable & Split the Initial Payload では、Ajax のリクエストにも Expires ヘッダーをつけることでキャッシュさせる方法について解説されている。Ajax のリクエストは動的なものが多いのでキャッシュさせることはあまりないことだが、URL に timpestampをつけると有効であるとのこと。Google Calendar はそうなっているとのこと。

Load Scripts Without Blocking では、スクリプトブロックについて解説されている。<script src=”A.js”> という記述では、並列ダウンロードや描画をブロックするとのこと。MSN では、script タグを動的に作ることでブロックを回避している。

Don’t Scatter Inline Scripts では、広告や非同期スクリプトを外部から読み込みときの Tips が解説されている。いわゆる、外部スクリプトの遅延ロードについての解説。IE だと、script タグに defer と追加すると Google Analytics のスクリプトを非同期に読み込めるとのこと。Firefox だと、createElement で動的に script タグを作る。

Fast Data at Massive Scale – lessons learned at Facebook は、ゲスト講義で Facebook の Robert Johnson 氏の講義。Facebook のインフラのアーキテクチャーが公開されているかなり貴重な資料。Facebook のパフォーマンスを計測した結果として、1/2 が PHP の実行時間、1/4 が memcached、1/8 がデータベースとのこと。ただし、1ねん前はほとんど memcached であったとのこと。そのころはスイッチ経由で PHP クライアントと memcached のやりとりをしたのをクラスタリングにした。もうすこし具体的な情報がほしかったな。

Shard Dominant Domains では、ドメインをわけることで並列ダウンロードしてページの表示時間を短くする方法について解説されている。Steve 氏のサイトでは、実際のデモとして同じドメイン版別のドメイン版、と用意されている。ブラウザによって、実装が異なっているが、HTTP 1.1 だと 1 サーバあたり 2 接続でダウンロードできるらしい。DNS のルックアップ回数を減らすルールと矛盾しそうなルールだが、イメージなどの固定なコンテンツには有効とのこと。

Optimize Images, Use Iframes Sparingly, Flush the Document Early では、イメージの最適化、iframe を控えめに使う、ドキュメントは早めにフラッシュすることについて解説されている。イメージの最適化では、さまざなツールが紹介されておりが CSS Sprites Generator というツールがあるとは知らなかった。

Serve Static Resources Cookie-Free, Reduce Cookie Weight, To WWW or not to WWW では、クッキーのサイズによってレスポンスタイムが変わることについて解説されている。

CSS Descendant Selectors, Forced Compression では、CSS のパフォーマンス向上に的を絞った解説がされている。ユニバーサルセレクタを使わない、DIV #navbar ではなく #navbar と指定する、LI .tight ではなく .li-tight と指定する、#navbar A ではなく .a-navbar と指定する。CSS 子孫セレクタによってはパフォーマンスに影響してくるというテスト結果も公開されていた。

State of Performance では、今までの講義のまとめて的なものであった。

ということで、ウェブサイトのパフォーマンスを向上させるテクニックがこれほど詳細にスタンフォード大学で講義があった。

このテクニックは、ブラウザ依存だったり、比較的大規模にならないと効果が目に見えないテクニックだけれど、とても勉強になった。

スタンフォード大学は、やっぱりすばらしい。

symfony の init-admin タスクをさらに改良してみた

先日、紹介した symfony の init-admin タスクを、さらに改良してみたので、今日はその内容について紹介します。

今回は、しばらく init-admin-plus を使っていて、いくつか不便なことに遭遇したため改良してみた。具体的には、次のとおり。

  • 入力値をチェックする validator(ファイルでいうと validator/edit.yml) で、最大文字数のチェックを自分で毎回指定するのがめんどう
  • 同じく validator で、必須のパラメータを指定するのがめんどう
  • 同じく validator で、特定のカラム型に対応する validator を指定するのがめんどう
  • config/generator.yml で、フィード名をデータベースの構造を見ながら指定するのがめんどう
  • 同じく generator.yml で、各画面ごとに表示する項目を指定する display をデータベースの構造をみながら指定するのがめんどう

これらは指定しわすれて不具合につながっていた状況を改善するべく、自動生成して楽をしたいというのが改良のきっけかです。

というわけで、指定されたモデルに対応するテーブル構造を取得するいい方法はないかなと symfony の propel まわりのソースコードを読んでみたところ、config/schema.yml を読むことでいけるということが分かったので、myPakePropelAdminGeneratorPlus に追加してみた。

 

やっていることはとても単純なので、coderepos にアップしたソースコードをみてもらうことにして、config/generator.yml と validator/edit.yml の雛型を準備する必要がある。

これらの雛型は、sfConfig::get(‘sf_root_dir’) の  data/generator/sfPropelAdmin/テーマ名/skeleton に格納されているので、これを変更する。

config/generator.yml の雛型は、次のようにします。次のファイルは、list のみですが create, edit も同様に指定します。

generator:
class: sfPropelAdvancedAdminGeneratorPlus
param:
model_class: ##MODEL_CLASS##
theme: admin
css: admin

#
# 共通フィールド名の設定
#
fields:
##GEN_FIELDS##

#
# TITLE一覧
#
list:
  title: “TITLE一覧”
  display: ##GEN_DISPLAY##
  fields:
  actions:
    _create: –
  filters:
  max_per_page: 20
  sort: id

 

具体的には、##GEN_DISPLAY## のところが [カラム名1, カラム名2,…] に置換される。

 

次に、validator/edit.yml の雛型は、次のようにします。

methods: [post]

fillin:
enabled: on

#
# バリデータ設定
#
fields:
##VALIDATOR##

 

具体的には、##VALIDATOR## のところがいっきに展開されます。これはカラムによって展開される内容が変わってくるけれど、例えば次のようになる。

methods: [post]

fillin:
  enabled: on

#
# バリデータ設定
#
fields:
  hoge{name}:
    required:
      msg: “name is required.”
  sfStringValidator:
    max: 255
    max_error: “This field is too long.”
     myDateValidator:
hoge{created_at}:
  myDateValidator:
hoge{updated_at}:
  myDateValidator:

この例だと、hoge というテーブルがあって name というカラムは必須で長さが 255 まで、created_at と updated_at は timestamp 型であるのでそのチェックを行うという設定で自動的に生成される。

 

これで、かなり symfony で管理画面系を生成するのが楽になって、validation を入れ忘れるというミスもなくなるはず。管理画面系は、けっこう作るのがめんどうなので、できるかぎり自動化を進めていきたいところです。

 

なお、symfony 1.0.18 で動作確認済で、sfPropelAdvancedAdminGeneratorPlus というプラグインは、知人から拝借した sfPropelAdvancedAdminGenerator という独自のプラグインを自分好みで変更したプラグインなので、もしかするともしかするとそのうち公開されるかもしれませんので毎日ググりながら楽しみに待つことにしましょう!

Ganglia のインストール方法

サーバの台数が多くなってくると、Cacti でいちいち監視対象のサーバを追加するのがめんどくさくなってきた。そこで、Ganglia をインストールしてみた。現時点での最新版は、バージョン 3.0.7。

CentOS でのインストールは、rpm が Ganglia から配布されているのでダウンロードしてインストールする。Ganglia は、PHP で書かれていて GD を使っている。データベースは使っていない。
Ganglia の構成をざくっとまとめておくと、Ganglia は次の 3 種類のプログラムで構成されている。

  • Ganglia Monitoring Daemon (gmond)

    • クライアント側にインストールするプログラム
    • 監視するクライアントにインストールするホスト、Ganlia は SNMP ではなくマルチキャストで通信する
    • gmond が /proc 以下から CPU、メモリの状況を XML 形式で出力してくれる
    • ポートは 8649 を使っているが、設定ファイルで変更することができる
  • Ganglia Meta Daemon (gmetad)

    • サーバ側にインストールするプログラム
    • クライアントのデータを収集するデーモン
    • gmetad が起動していないと、Ganglia の Web UI を表示することができないので注意
  • Ganglia PHP Web Frontend

    • サーバ側にインストールするプログラム
    • 監視するメイン画面、rrdtool などで可視化して表示する
    • イメージは、ライブデモを見ると分かる

何はともあれ、まずはインストールしてみる。

  • SourceForge から、次の 3 種類の rpm をダウンロードする
    • ganglia-gmetad-3.0.7-1.i386.rpm
    • ganglia-gmond-3.0.7-1.i386.rpm
    • ganglia-web-3.0.7-1.noarch.rpm
  • ダウンロードした rpm を、それぞれインストールする、その都度必要なパッケージがあったらインストールする
  • Ganglia の Web UI が、/var/www/html/ganglia へインストールされるので、Apache などでアクセスできるようにする

今回は、Ganglia のサーバとクライアントは同じコンピュータにインストールしている。

次に gmond の設定をしてみる。gmond の設定ファイルは、/etc/gmond.conf を編集する。変更する箇所は、次のとおり。

cluster {
name = “My cluster”
owner = “unspecified”
latlong = “unspecified”
url = “unspecified”
}

udp_send_channel {
mcast_join = 224.0.0.1
mcast_if = eth0
port = 8649
ttl = 1
}

udp_recv_channel {
mcast_join = 224.0.0.1
mcast_if = eth0
port = 8649
bind = 224.0.0.1
}

マルチキャストの設定をする。CentOS 5.1 では、次の内容で /etc/sysconfig/static-routes を作成して、sudo /etc/init.d/network reload する。

any net 224.0.0.0/4 dev eth0

マルチキャストの設定が正しいかどうかは、netstat -rn を実行して確認することができる。

$ netstat -rn

224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth0

gmond を起動してみる。

$ sudo /etc/init.d/gmond start

とここで、次のようなエラーがでた。

slurpfile() open() error on file /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory

なんか、このあたりの問題のようだ。trunk ではすでに修正されているらしいが、上のエラー以外にも変更が加わっているので、次のようなパッチにしてみた。

— ./libmetrics/linux/metrics.c-org 2008-07-17 17:33:40.000000000 +0900
+++ ./libmetrics/linux/metrics.c 2008-07-17 17:49:56.000000000 +0900
@@ -39,6 +39,8 @@
#endif
char proc_cpuinfo[BUFFSIZE];
char proc_sys_kernel_osrelease[BUFFSIZE];
+
+#define SCALING_MAX_FREQ “/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

char sys_devices_system_cpu[32];
int cpufreq;

@@ -169,13 +171,20 @@
{
g_val_t rval;
char * dummy;
+ struct stat struct_stat;

num_cpustates = num_cpustates_func();

– cpufreq = 1;
– rval.int32 = slurpfile(“/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_fre
q”, sys_devices_system_cpu, BUFFSIZE);
– if ( rval.int32 == SYNAPSE_FAILURE )
– cpufreq = 0;
+ /* scaling_max_freq will contain the max CPU speed if available */
+ cpufreq = 0;
+ if ( stat(SCALING_MAX_FREQ, &struct_stat) == 0 )
+ {
+ rval.int32 = slurpfile(SCALING_MAX_FREQ, sys_devices_system_cpu, BUFFS
IZE);
+ if ( rval.int32 == SYNAPSE_FAILURE )
+ cpufreq = 0;
+ else
+ cpufreq = 1;
+ }

パッチをあてたバージョンをインストールしたいので、SRPM をインストールして SPEC ファイルを書き換えてパッチをあてた RPM を初めて作ってみた。パッチを作るときには、diff コマンドを使うけれど、ソースコードのファイル名の先頭に ./ と書いた方がいい。書かないと、rpmbuild したときにパッチを当てるファイル名を入力が必要になってしまう。

$ diff -uNr ./libmetrics/linux/metrics.c.org ./libmetrics/linux/metrics.c > ~/rpm/SOURCES/ganglia_metrics.c.patch

これで、gmod はちゃんと起動した。確認するには、telnet localhost 8649 して XML データが返ってくれば問題なし。

次に gmetd の設定をする。gmetd の設定は、/etc/gmetd.conf を編集すればいい。次の行を変更する。

data_source “My hoge” localhost

ローカルホストだけ監視対象に追加する。

gmod を設定したら、gmod を起動する。

$ sudo /etc/init.d/gmod start

無事起動した。

現在、収集する情報の種類は、次のコマンドで確認することができる。

$ /usr/sbin/gmod -m

Ganglia の Web UI を見てみると、Ganglai のウェブ管理画面で PHP のエラーが出るので、次の二つのパッチを書いて対策した。

— ./web/get_context.php-org   2008-04-08 15:45:09.000000000 +0900
+++ ./web/get_context.php       2008-04-08 15:46:26.000000000 +0900
@@ -42,9 +42,10 @@
$clustergraphsize = isset($_GET[“z”]) && in_array( $_GET[ ‘z’ ], $graph_sizes_keys ) ?
escapeshellcmd($_GET[“z”]) : NULL;
# A stack of grid parents. Prefer a GET variable, default to cookie.
+$gridstack = “:”;
if (isset($_GET[“gs”]) and $_GET[“gs”])
$gridstack = explode(“:”, clean_string( rawurldecode($_GET[“gs”] ) ) );
-else
+else if (isset($_COOKIE[“gs”]))
$gridstack = explode(“:”, clean_string( $_COOKIE[“gs”] ) );

# Assume we are the first grid visited in the tree if there are no CGI variables,

— ./web/header.php-org        2008-04-08 15:46:32.000000000 +0900
+++ ./web/header.php    2008-04-08 15:48:16.000000000 +0900
@@ -53,8 +53,7 @@
{
# Use cookie so we dont have to pass gridstack around within this site.
# Cookie values are automatically urlencoded. Expires in a day.
–      $gscookie = $_COOKIE[“gs”];
–      if (! isset($gscookie))
+      if (! isset($_COOKIE[“gs”]))
setcookie(“gs”, $gridstack_str, time() + 86400);
}

さらにロードアベレージのグラフをみると、なぜか縦軸のメモリに m がついていて気になるので、これも修正した。rrdtool のパラメータを調整すればいいので、次のようなパッチを書いた。

— ./web/graph.php-org 2008-07-22 14:21:25.000000000 +0900
+++ ./web/graph.php 2008-07-22 15:06:04.000000000 +0900
@@ -14,6 +14,13 @@
# ATD – TODO, should encapsulate these custom graphs in some type of container,
then this code could check list of defined containers for valid graph labels.
$graph = isset($_GET[“g”]) && in_array( $_GET[‘g’], array( ‘cpu_report’, ‘mem_r
eport’, ‘load_report’, ‘network_report’, ‘packet_report’ ) ) ?
$_GET[“g”] : NULL;
+if (isset($_GET[“m”])) {
+ $m_value = $_GET[“m”];
+ if (substr($m_value, 0, 5) === “load_”) {
+ $graph = “load_report”;
+ }
+}
+
$grid = isset($_GET[“G”]) ?
escapeshellcmd( clean_string( rawurldecode( $_GET[“G”] ) ) ) : NULL;
$self = isset($_GET[“me”]) ?

ようやく、Ganglia にアクセスできる環境が整った。そろそろ、修正版をリリースしてほしい…。><

Ganglia を自分でビルドするときは、Web UI の RPM(noarch) も必要なので、64 ビット環境ときは次のコマンドでビルドする。32 ビット環境の場合は、x86_64 を i386 に変更する。

$ rpmbuild -ba –target noarch,x86_64 ~/rpm/SPECS/ganglia.spec

Ganglia の SPEC ファイル、パッチ 3 種類、ビルドした 64 ビット用の RPM をおいておくので、よかった使ってください。

あとは、各クライアントへ gmod デーモンを動かすだけで自動的に Ganglia のウェブ管理画面に反映されるようになる。

また、ganglia のウェブ管理画面はテンプレートして切替えられるようになっている。設定は、/var/www/html/ganglia/conf.php の $template_name を変更するだけ。デフォルトのテンプレートの他には Rock というテンプレートが入っている。

テンプレートも、tpl という拡張子の PHP ファイルなので変更も簡単なところはいいところか。

sshの多段接続がものすごい便利な件

普段、開発するときにあるサーバを経由して SSH しながら開発作業をしていたが、どうも効率がかなり悪いと感じていた。

そのときの、ネットワーク構成は次のようになっている。

[macbook]

 |

(インターネット)

|

(ルータ)

|

[proxy]

|

[s1]

s1 は、物理的にインターネット回線にはつながっていない。

 

作業マシンの macbook から、s1 にログインして開発をするには、次の手順を踏む必要がある。

  1. [macbook] $ ssh proxy
  2. [proxy] $ ssh s1
  3. [s1] $ vi …
s1 はサーバなので使い慣れている emacs が入っていないのと、s1 で出力したログなどのデータをローカルにコピーするときとかプロキシサーバを経由しているため、かなり非効率になっていた。
そこで、何かいい方法がないかなと調べてみたところ、次の情報を見つけた。
.ssh/config に ProxyCommand として書くと、[macbook] から直接 [s1]にSSH経由でログインすることができる方法が紹介されていた。
もちろん、SSH はすべて公開鍵認証なので、[macbook] の $HOME/.ssh/config に次のように追加した。
Host s1
  HostName s1.example.com
  User n0ts
  ProxyCommand nohup ssh -l naoya proxy nc %h %p
HostName は、proxy から s1 へ接続するときの名前を設定する。この名前は、[macbook] から名前解決ができなくても問題ない。User を指定しているのは、proxy と s1 でログインするユーザが違うため。User の方に指定したユーザ名は s1.example.com にログインするときのユーザ名になる。最後に ProxyCommand には proxy へ接続するときのユーザを指定する。
あとは、次のように SSH するだけで、直接 s1 へログインすることができる。
[macbook] $ ssh s1
もちろん、sshfs でも使うことができる。
これで、毎回 proxy にログインしなくてもよくなって、かなり快適になった。

The Art of Capacity Plaining

昨日、パソナテック10周年記念 PTカンファレンスVol.6 インフラエンジニア討論会2008 ~インフラエンジニア進化論~に行ってきた。自称インフラエンジニアとしては、なかなか刺激のあるイベントであったが、その中で mizzy さんが「The Art of Capacity Plaining」という本を最近読んでいると聞いたので、調べてみた。

この本は、Book review などの情報源がたくさんあって、Flickr のオペレーションエンジニアの John Allspaw 氏が書いたいわゆるサーバの増強計画をどのように行うかについて書かれた本であるとのこと。

最近、仕事でも急にサーバを増やすように言われて四苦八苦している僕にとっては、かなりタイムリーな本だ。O’Reilly で紹介されている記事から含まれているトピックスを訳すと、次のような内容が含まれている。

  • 計測、デプロイツールを評価する方法
  • ストレージ、データベース、アプリケーションサーバへのキャパシティ解析とその予測
  • 簡単に(サーバを)追加できるアーキテクチャーのデザイン方法、キャパシティの計測方法
  • 突発的なアクセスへの対処方法
  • 急上昇と爆発的な成長の予測
  • EC2 のようなクラウドサービスは、どのような内部的なキャパシティストレージに合うか(ちょっと意味不明)

どのような紹介が highscalability.com にも紹介されていた。highscalability.com は、ずっと購読していたが RSS の URL が変わったようでまったく更新をチェックしていなかった。。。インフラまわりをやっている人は、highscalability.com をチェックすることは必須であると思う。このサイトは、大規模なサイトがどのような技術を使っているかの情報源をまとめた貴重なサイトです。

John Allspan 氏は、1999 年からニュースマガジンや SNS のサイトを担当してきた経歴の持ち主らしいので、かなり勉強になりそう。John Allspan 氏のブログは、Kichen Soap として公開されている。同氏は、昨年の MySQL コンファレンス 2007 や Web 2.0 Expo や Velocity でも講演していた。これらのスライドは、すでに公開されていて、チェックするのを忘れていたので、メモしておく。

まずは、MySQL Conf 2007 の「Capacity planning for LAMP」から。スライドは、PPT あるいは PDF で公開されている。PDF の方は、スライドの他にもメモが書いてあるので、PDF の方をチェックするといいと思います。

  • 自分のサービスには、どのくらいのデータベースサーバ、ウェブサーバサーバ、共通ストレージ、スイッチなどが必要かついて問い正している
  • Flickr の数字が公開されていて、squid キャッシュに合計 35M(この M はミニオンという意味かな…)とすると 3,500 万枚くらいの写真があって、squid のメモリに 2M くらいの写真があって、470M くらいの写真がそれぞれ 4 〜 5 くらいのサイズあって、38k req/sec くらいの memcached にアクセスがあって 12M くらいのオブジェクトをもっている、2PB(!) の物理的なストレージがある
  • このプレゼンでは、MySQL、squid、memcached について焦点をあてて話すとのこと
  • サーバのキャパシティを考えるにあたって、計画(何を?なぜ?いつ?)、デプロイ(インストール、設定、管理)、計測(グラフ化)の3つの主パートについて考えてみる
  • MySQL は disk I/O、squid は disk I/O あるいは CPU、memcached は CPU あるいはネットワークの上限をを把握することが重要
  • Flickr では、Ganglia を使っている、貴重なスクリーンショットが公開されている
  • Ganglia で、iostat で計測した結果をグラフにするためのシェルスクリプトが公開されている
  • memcached の Gets/sec もグラフにしている、スライドで紹介されていた addon のページ http://wtf.ath.cx/ はデッドリンクだったが、別のものがあった
  • GraphClick という 8 ドルの MRTG グラフを解析するためも OSX 用のシェアウェアが便利
  • Flickr の MySQL サーバで使っている、DELL Power Edge 2950に 6 個のディスク 15K RPM の SCSI、RAID10、16GB RAM、クアッドコアCPU、というスペックの MySQL のクエリーグラフが公開されている、グラフをみると秒間 1.3K くらいの SELECT クエリーを捌けているが、CPU は 2% までいかないとのこと
  • 次に MySQL Disk IO のグラフが公開されている、グラフをみると iowait が 10% くらいになっているが日々変わるのでよく監視している
  • Squid へのリクエストとヒット数やヒット率、LPU の reference age、レスポンスタイムを ganglia のグラフにしている、80% くらい squid キャッシュにヒットしていて、レスポンスタイムは 50ms 以内くらい
  • OSS のデプロイツールとして、SystemImager/SystemConfiguratorCVSupSubconが紹介されている

かなり勉強になった、昨日でも mixi や楽天はなんでもグラフ化していると言っていたが、Flickr でも ganglia でさまざまなものをグラフ化している、僕も ganglia を使っているけれど MySQL とか memcached などのカスタムグラフは追加していないでやらないとけないと思った。レスポンスタイムもかなり重要なので、僕が管理しているサービスのレスポンスタイムもグラフに出してみたいと思った。Subcon は便利そうだと思ったがまだ開発中っぽい。

次に web 2.0 expo での「Capacity Planning for Web Operations」の資料に目を通してみた。Slideshare でも同じ内容が公開されていた。

  • あるクリスマスの Yahoo! トップページの爆発的なトラフィックのグラフが紹介されていた
  • 同氏の来年何台のサーバが必要かについてファイナンス部と相談した
  • どのくらいサーバ必要か判断するには、計測することが重要
  • 前と同様に ganglia での Flickr でメール経由で1分あたりどのくらいの写真がアップロードされているかを示すグラフが公開されていた、グラフをみると1分あたりメールで40から50くらい写真がアップロードされていた!
  • 写真がアップロードされてからの写真の処理枚数や処理時間(おそらくリサイズの処理だと思われる)のグラフが公開されていた
  • ベンチマークをとって、上限を見つけることが重要、そのときにはできるだけ本番のデータを使うこと
  • サーバごとにどの部分が重要か示されている、ロードバランサーは前後のネットワーク、ウェブサーバは CPU とメモリとディスク使用量と disk I/O
  • ベンチマークツールとして、Siegehttperf/autobenchsysbenchが紹介されている
  • 67台の CPU のコア数 2 のウェブサーバを 18台の 8 コアに交換したときのロードアベレージのグラフが公開されている、グラフをみるとロードアベレージが半分くらいまで下がっている!さらにさまざまな数字の比較も公開されていて、消費電力が 70% 削減されて、49U のラックスペースが開いたのこと!でかつ負荷も半分になったと!!!
  • 最後に Flickr の数字が紹介されちえる、ピーク時で 1 秒あたり 32,000 枚の写真が保存されている!、1日あたり 6-8TB のディスクを使用する!、Yahoo! Photos から統合に 1 日あたり 34TB くらいのディスクを使っている、1日あたり 3M のアップロードがあって、ピーク時に 1 秒あたり 60 枚の写真のアップロードがある!

ここで紹介されたベンチマークが使ったことがないので試してみる。httperf や sysbench が便利そう。コア数の多い CPU にリプレイスする意味は充分になることが分かった。僕の管理しているサーバの CPU は、全部 4 コアなので、すでに稼働している 2 コアのサーバは半分の台数で 8 コアのサーバとして充分に置き換え可能なことが分かった。

最後に Velocity での「Capacity Management」の資料に目を通してみた。正確なタイトルは、Capacity Management for Web Operations。

  • キャパシティとパフォーマンスは、別の意味
  • ベンチマークをとて限界を見つけることの重要性を強調している
  • MySQL のレプリケーション遅延のグラフ(mysql_slave_secs)を公開して、あるとき 50 秒くらいのレプリケーション遅延が行ったことで、データベースの上限を見つける例として紹介している、さらにそのときの disk iowait(diskio_iowait)のグラフを示して disk I/O wait が 40% くらいになるとレプリケーション遅延が発生しているとのこと
  • ウェブサーバの CPU グラフを紹介て、85% くらいまでを安全な上限としてみるのがいいとのこと
  • キャパシティ状態の数字が公開されいて、12,628 の nagios による死活監視、1314 台のホスト、6 つのデータセンター、4 つの farms(おそらく、flickr の写真の URL にある farmX.flickr.com の数)、farm は東西に二つのデータセンターがある
  • Squid のリクエストで下限あるいは上限でアラートを設定している
  • 写真の変換処理を行っていた DELL PowerEdge 860sHP DL140 G3s に置き換えた(CPU のコア数は 4 から 8 にした)が、CPU の使用率は変わらなかったが1分あたり処理できる写真の数の上限が 45 から 140 にくらいなったというピーク時のグラフが紹介されている!
  • そのときの数字として、サーバの台数が 23 台から 8 台、消費電力が三分の一、75% くらい高速化した、23U から 8U のラックでよくなった
  • dshという複数台のサーバに同時にコマンドを実行するツールが紹介されている

これもかなりためになった。写真の加工などいわゆる CPU を使うサーバはコア数を倍にすると、なんと三分の一で済んでしまうことが分かった。CPU の使用率はそのまだけれど、パフォーマンスが向上することも分かった。

あと、さまざまなグラフを一つのツールで統合して、そのグラフからシステムのパフォーマンスの上限を見極める重要さを実感できた。

ということで、かなりためになるので、思い切って本を購入してみた。初めての技術洋書になるけれども、ゆっくりでもいいから頑張って読んでみようと思う。

  • 1
  • 2