2009年、あけましておめでとうございます！

2009年、いよいよ始まりました。

今年の豊富は、次のとおりです。

• 人への思いやりを持てるようにする
• 行動力を発揮する
• モテる

今年もよろしくお願いします！

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 して、設定を反映させる

Tags: vmware linux

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

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

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

Tags: postgresql

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 の開発が激しく、機能も充実してきているのであとでエントリしたいと思う。

Tags: centos

年の瀬ということもあって、仕事マシンとして大活躍してくれた 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 を試してみる。

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 のシェルスクリプトを見ると分かります。

Tags: sysstat

スタンフォード大学で、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 専用のパケットスニッファ、Firebugs、Y 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 にクライアント側のパフォーマンスデータを計測するプラグインがあることは初めて知った。

さらに 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 のコードからスペースなど余計な文字を除去して転送するデータ量を少なくする方法が解説されている。JSMin や YUI Compressor や DoJo 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 では、今までの講義のまとめて的なものであった。

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

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

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

Tags: stanford

先日、紹介した 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 という独自のプラグインを自分好みで変更したプラグインなので、もしかするともしかするとそのうち公開されるかもしれませんので毎日ググりながら楽しみに待つことにしましょう!

Tags: symfony

サーバの台数が多くなってくると、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 ファイルなので変更も簡単なところはいいところか。

Tags: ganglia

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

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

[macbook]

 |

(インターネット)

|

(ルータ)

|

[proxy]

|

[s1]

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

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

1. [macbook] $ ssh proxy
2. [proxy] $ ssh s1
3. [s1] $ vi …

[macbook] $ ssh s1