Archive for September, 2010

github Tips #1

September 26th, 2010 by naoya | No Comments | Filed in day

github.com で、fork したブランチに fork 元の変更をマージする方法を調べてみました。

例として、「git://github.com/nakazawa/github-services.git」fork 元の HEAD、「git://github.com/naoya/github-services.git」を fork 先とします。

fork したブランチをもってきます。

$ git clone git://github.com/naoya/github-services.git

fork 元のリモートリポジトリを upstream として定義します。

$ cd github-services

$ git remote add upstream git://github.com/nakazawa/github-services.git

$ git fetch upsteam

あとは、さきほど定義したリモートリポジトリからオブジェクトをダウンロードして、マージします。

$ git fetch upstream

$ git merge upstream/master

たったこれだけで fork 元の変更をマージすることができます。

また、fork 元の HEAD が更新されたから、fetch と merge を実行すればいいはずです。

この情報源は、github のヘルプページでした。github を使いこなすには、github のヘルプページを一通り見たほうがいいかもしれませんね。help.github は、今のところ英語版だけなので、日本語版を作成するもありかなと思いました。

Tags:

Apache + Tomcat でエラーログが出る

September 16th, 2010 by naoya | No Comments | Filed in day

Apache + Tomcat を使っていると、ErrorLog に、次のログがでることがたまにあります。

[Thu Sep 16 21:05:17 2010] [error] [client x.x.x.x] proxy: error processing end, referer: http://example.jp

このエラーログをなんとかしようと、Apache のバグデータベースをみてみたところ、同じ内容が報告されていました。

Bug 46415 – Error “proxy: error processing end, referer…” should be debug not error

この報告によると「mod_proxy が応答を送信する前にクライアント側のコネクションが閉じられてしまうとき発生するのでエラーではなくデバッグレベルでログを出すべきだ」となります。

そして、エラーログのレベルをデバッグレベルに下げる変更が、2010年8月にコミットされています。

--- httpd/httpd/trunk/modules/proxy/mod_proxy_ajp.c	2010/08/06 17:04:40	983056
+++ httpd/httpd/trunk/modules/proxy/mod_proxy_ajp.c	2010/08/18 08:31:36	986591
@@ -471,7 +471,7 @@ static int ap_proxy_ajp_request(apr_pool
                     }
                     if (ap_pass_brigade(r->output_filters,
                                         output_brigade) != APR_SUCCESS) {
-                        ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+                        ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
                                       "proxy: error processing body.%s",
                                       r->connection->aborted ?
                                       " Client aborted connection." : "");
@@ -489,7 +489,7 @@ static int ap_proxy_ajp_request(apr_pool
                 APR_BRIGADE_INSERT_TAIL(output_brigade, e);
                 if (ap_pass_brigade(r->output_filters,
                                     output_brigade) != APR_SUCCESS) {
-                    ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+                    ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
                                   "proxy: error processing end");
                     output_failed = 1;
                 }

ということで、このパッチを自分が本番環境で使っている Apache にあててみました。

これでしばらく様子を見たいと思います。

スケーラビリティに関する６つの教訓

September 12th, 2010 by naoya | 2 Comments | Filed in day

High Scalability – High Scalability – 6 Scalability Lessons から、スケーラビリティに関する６つの教訓が紹介されていました。

  • レッスン１：高負荷下での active/active DRBD  クラスター上に Smarty コンパイル(Smarty compile) されたものやテンプレートキャッシュをおくと、そのうちにサーバーは落ちるだろう
  • レッスン２：箱から出してすぐに使えるように設定を使うな
  • レッスン３：単一ポイントでの競合は、そのうちボトルネックになるだろう
  • レッスン４：進歩を計画する
  • レッスン５：可能なかぎりデータベースに仕事をさせよう データベースの負荷を memcached などに肩代わりしてもらい、可能なかぎりデータベースに仕事をさせないようにしよう
  • レッスン６：ファイルシステムは、領域 / i ノードを食いつぶす

Tags:

tcptrack

September 6th, 2010 by naoya | 1 Comment | Filed in day

tcptrack というコマンドを知りました。tcptrack は、現在の TCP コネクションの情報を top のように表示してくれるツールです。

さっそく、試してみました。

$ wget http://www.rhythm.cx/~steve/devel/tcptrack/release/1.3.0/source/tcptrack-1.3.0.tar.gz

$ sudo yum install libpcap-devel

$ rpmbuild -ta ./tcptrack-1.3.0.tar.gz

これで、さくっと RPM を作成することができます。

さっそく使ってみます。

$ sudo tcptrack -i eth0

そうすると、次のような画面になります。デフォルトだと、２秒おきに表示が更新されます。

libcap を使って、現在の TCP コネクション情報を取得しているため、けっこうな負荷がかかりますので、TCP コネクション数が多いサーバでは注意して使った方がいいと思います。

とはいえ、手っ取り早く現在のサーバの TCP コネクション情報を取得したいときには便利なコマンドです。

tcptrack の詳しい使い方は、man tcptrack するか、こちらで確認してみてください。

Tags: