Postfixのログの”delays”について
2008/02/21 13:05 posted by kunkichi
今、仕事で短期的なメールサーバを構築しているんだけど、一通り作業が終わったのでテストでメールを送信してたんだけど、なーんか相手先に送信するまでに時間がかかるなぁと思って、別のターミナルでログを tail -f で流していたらこんなログが目に付きました（一部伏せてます）。
Feb 21 12:04:00 mail postfix/smtp[4938]: XXXXXXXXXXXX: to=<xxxxxxxx@example.com>, relay=mail.xxxxxxxx.com[XXX.XXX.XXX.XXX]:25, delay=56, delays=0.04/0.01/54/1.6, dsn=2.0.0, status=sent (250 2.0.0 XXXXXXXXXXXX Message accepted for delivery)
delayは当然大きいのだけど、その後の”delays“という項目、なんか数字が4つ並んでいて、全部足すと大体delayと同じになる。んー、これはもしかしてどこの処理で遅くなっているかがわかるのかなと推測して、ってことでググってみたら、
[postfix-jp: 2334] Re: delays
>delays=6.5/0/0/0.05 ＜？？？
>
>意味か文献場所をご教授ねがいます
RELEASE_NOTES に書いてあるみたいですが。
—————————————————————–
- Better insight into the nature of performance bottle necks, with
detailed logging of delays in various stages of message delivery.
Postfix logs additional delay information as “delays=a/b/c/d”
where a=time before queue manager, including message transmission;
b=time in queue manager; c=connection setup time including DNS,
HELO and TLS; d=message transmission time.
—————————————————————–
postfix の src を展開したディレクトリィの README_FILES/ にあり
ます。
やっぱりそういうことですか。
a=time before queue manager, including message transmission;
b=time in queue manager
c=connection setup time including DNS,HELO and TLS
d=message transmission time.
ちなみに僕のテストの場合は、Cで時間がかかっていてなんでかなと思ってログを遡ってみると、1回送信しようとしたのだけどconnection timeoutして再送後成功してたからということでした。
何年もメールサーバ管理してたのに知らなかったよ、でもqmailが多かったし、と言い訳しておきます。
Category: Server | コメント＆トラックバック（0）
さくらにインストールしたTracがまたおかしくなった
2008/02/12 00:56 posted by kunkichi
このサイトは、さくらインターネットのレンタルサーバを使っているのだけど、どうもOSのバージョンアップをしたらしく、ソースからインストールしていたもの、特に Trac が全然動かなくなっていた。
なので、ちょっと前に以下のサイトを参考にビルドし直したのだけど、気づいたらまた動かなくなってる、、、orz
カサヒラボ : さくらのレンタルサーバの「FreeBSD 6.1」バージョンアップで、trac + Subversion がエラーになってる
一つ前のエントリと同じく、
カサヒラボ - さくらのレンタルサーバが、「FreeBSD 6.1-RELEASE」になっている。
によって、trac + Subversionもエラーになってるっぽい。
エラーメッセージはこんな感じ。
Traceback (most recent call last):
File "/home/cafechantant/local/lib/python2.4/site-packages/trac/web/main.py", line 406, in dispatch_request
dispatcher.dispatch(req)
File "/home/cafechantant/local/lib/python2.4/site-packages/trac/web/main.py", line 191, in dispatch
chosen_handler = self._pre_process_request(req, chosen_handler)
File "/home/cafechantant/local/lib/python2.4/site-packages/trac/web/main.py", line 263, in _pre_process_request
chosen_handler = f.pre_process_request(req, chosen_handler)
File "/home/cafechantant/local/lib/python2.4/site-packages/trac/versioncontrol/api.py", line 73, in pre_process_request
self.get_repository(req.authname).sync()
File "/home/cafechantant/local/lib/python2.4/site-packages/trac/versioncontrol/api.py", line 91, in get_repository
raise TracError('Unsupported version control system "%s". '
TracError: Unsupported version control system "svn". Check that the Python bindings for "svn" are correctly installed.
うーん、前回と同じエラーだ、、対応したはずなのになぁ、、
とりあえず再ビルドしたら直ったけど、さくら側でなんかいろいろやってるんだろうか？まあこっちが勝手にやってることだからしょうがないのだけど、動かなくなるのはちょっと困ったなぁ、、、
別のところに移そうか検討中。
Category: Server, Diary | コメント＆トラックバック（0）
えらいこっちゃ
2008/01/01 18:53 posted by kunkichi
えらいところからリンクを貼られてしまったなぁ。ペパボの宮下さんの記事。
新春特別企画・2008年を展望する!：2008年のオープンソースによるシステム管理｜gihyo.jp … 技術評論社
Cobblerに関しては，インストールや基本的な設定に関する情報やオフィシャルドキュメントの日本語訳サイトなど，日本語の情報も充実しています。
日本語の情報も充実、汗、、、
すいません、最近忙しくてほとんど更新できてないんですよ、バージョンも追いつけてないですし、滝汗、
puppetと組み合わせたら無敵やなぁと思ってガンガン翻訳してた、数ヶ月前に戻りたいす、泣
Category: Server, Diary | コメント＆トラックバック（0）
O’Reilly Japan News 第118号
2007/11/24 20:01 posted by kunkichi
毎月恒例のオライリー・ジャパン・ニュース。年末だしそろそろかなー（爆）
3. Web直販キャンペーン
■『2008年オライリーカレンダー』プレゼント
2008年オライリーカレンダーをご注文いただいたみなさまにプレゼント！11月22日受注分からご注文書籍（新刊予約分を含）に同梱いたしますので、この機会をご利用ください。なお、Webでのキャンペーン公開は11月27日予定です。
ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
では早速品定め（爆）とりあえず12月の新刊で目についたのはこんなところ。
(more…)
Category: Programming, Server, Book | コメント＆トラックバック（0）
データセンターで省スペース・省電力を成功させる10のヒント
2007/11/02 23:54 posted by kunkichi
わはは、我ながらなんかIDEA*IDEAっぽいタイトルに凹む、、、（爆）
メール整理していたら、ちょっと前にSunの販促メルマガにこんなのが載ってたのを見つけた。ま、Sunの宣伝半分なのは十分承知の上、ちょっとレビューしてみようというエントリ。いくらデータセンターとはいえ消費電力を下げる努力はやるにこしたことはないと思うし。
Sun Inner Circle Vol.53 - 環境配慮型データセンターをつくるための10のヒケツ
■省スペース・省電力を成功させる10のヒント
今月のInner Circleでは、サンのベスト・プラクティスを共有し、他のデータセンターでも同様の結果を得られる10の方法について、ネルソンとそのチームに話を聞きました。
- サーバ・ラック内のシステムがどの程度年代物かを確認する
- その他エネルギーとスペースを大量に消費するものを特定し、交換する
- 迅速かつ長期的な切り替え計画を実施する
- IT管理作業は設備担当者が実施する
- 同時更新で、停電の可能性をなくす
- 同様のアーキテクチャにアップグレードして移行の問題を回避する
- 仮想化とコンテナ技術を検討する
- ラックレベルで測定する
- 環境全体ではなく、高温箇所を冷却する
- 冷却方法を見直して、建築費を削減する
1. サーバ・ラック内のシステムがどの程度年代物かを確認する
エネルギー効率というか、消費電力辺りの性能という意味では、古いシステムは確かに効率が悪いものが多いと思うけど、消費電力量だけで考えると、最近のもののほうが性能が上がってる分、消費電力量は多くなっている。一昔前のPentium3の性能と消費電力は、用途によっては今でも十分使えるレベルにあると思うし、実際、商用のファイアウォールや負荷分散装置ではPentium3が採用されているケースもあったので、一概に古いものはダメとは思わない。
ただし、Opteronなんかの消費電力は目を見張るものがあるので、徐々にリプレースはされるのかなとは思うけど。
2. その他エネルギーとスペースを大量に消費するものを特定し、交換する
これは同意。しかし例に出てくるV880って触ったことないけど、これならどんなサーバに変えても消費電力とラック使用率さげるんじゃねえかと思ってしまった。
3. 迅速かつ長期的な切り替え計画を実施する
おおむね同意なんだけど、「3年でリプレース」ってちょっと難しくないかなぁ。リース契約とかも５年が一般的な気がするんだけど。ただ計画性は大事だよね。
あと、「奨励金受給」ってあるけど、これ日本の自治体とか電力会社にこういうプログラムあるの聞いたことないなぁ。関西圏でこういうのがあればだれか教えてください。
4. IT管理作業は設備担当者が実施する
あー、あー、聞こえなーい(∩ ﾟдﾟ)
いや、財務担当者と仲良くしなさいってことでしょ。ええ、やりますとも。だから金出してくれ。
5. 同時更新で、停電の可能性をなくす
これ言ってることがよくわかんないなぁ、特に同時ってところ。計画的にやるのはもちろん、ステージングも可能な限りやるけど、いくらステージングがあったとしても本番で失敗することってあるから、切り戻しを考えると、旧システムも同時に動かしておくよね、普通。同時ってのはどういう意味なんだろ？
6. 同様のアーキテクチャにアップグレードして移行の問題を回避する
これって更改する時は単にHWだけにしとけってこと？変更箇所が多いのはトラブルの要因になるから普通やらないよね？
7. 仮想化とコンテナ技術を検討する
ここは宣伝〜（笑）
いや、まあ仮想化はこれからのトレンドだとは思います。収容効率もよくなるし管理も楽になると思うし。でもね、まだパフォーマンスとかスケールを予想するのが難しい気がするんだよね。前にSunの営業がプレゼンしにきたことがあるんだけど、ちょっとよく言い過ぎじゃねえ？とか思ったし（笑）それに、仮想化とかでリソースを１台とかに集中しちゃうとその１台が落ちたときの影響もでかくなると思うんだよね。
ただ、それは半分として、調査・検討はしていかないと行けないとは思う。
8. ラック・レベルで測定する
普通にやってない？これ。
9. 環境全体ではなく、高温箇所を冷却する
あー、これは一時期APCのカタログを見て気になっていた。これやってみたいなー。
10. 冷却方法を見直して、建築費を削減する
あ、今分かった、これデータセンター運用側に対する販促だったのか（爆）
まあ、販促メールなので、全部鵜呑みにはできないし、全般的に説明が足りない印象はある。でも省電力に対する取り組みは環境だけじゃなくて企業のコストダウンっていう意味でもものすごく意味が出てくると思っているので、業界全体でもっと積極的に進めてもらいたいところ。
Category: Server | コメント＆トラックバック（0）
TurboLinux11Serverは驚速（？）らしい
2007/10/31 21:03 posted by kunkichi
『Enterprise Watch』から。
エッジ環境向け最新サーバーOS「Turbolinux 11 Server」
ターボリナックス株式会社は10月31日、エントリからミッドレンジサーバー市場に向けたLinuxサーバーOSの新版「Turbolinux 11 Server」を発表した。11月29日から販売を開始する。
まだ生きていたのか（爆）ま、それはともかく、
特長は、企業のフロントエンドで必要とされるWeb系機能やソリューションを標準で搭載するとともに、Web系パフォーマンスを従来の1.5倍強に向上した点。
ふむふむ。
・・・。また、Webシステムで求められる負荷分散を実現するため、ソフトウェアロードバランサの「Cluster LoadBalancer」も標準搭載した。
そのほか、新プロセススケジューラ「CFS（Completely Fair Scheduler）」の採用、新メモリ管理の「SLUBアロケータ」への移行をはじめ、さまざまな主要コンポーネントが機能強化されている。
なるほど。OS側ではある程度チューンが済んだ状態で出荷されるという感じかな。
個人的にはある程度までいくと、ソフトウェアよりもハードウェアのほうがパフォーマンス的にはボトルネックになることが多いとは思うんだけど、パフォーマンス・チューニングは結構難しいし、買った時点である程度出来上がっているのはいいな。
その他エッジ向けということでセキュリティにTOMOYO LINUXを採用するなど結構意欲的だと素直に思う。アップデートも５万/5年とコスト的にも悪くはないし。5年使えたら十分元は取れる気がするので素直にリプレースできそう。
まあそれでも台数が増えてくるとやっぱりコストは気になるんだけど、老舗ディストリビューションだしがんばってほしいな。
Category: UNIX, Server | コメント＆トラックバック（0）
O’Reilly Japan News 第117号
2007/10/19 22:39 posted by kunkichi
毎月楽しみにしているオライリー・ジャパン・ニュースが来ました。さて今月のプレゼントは、、、（順番が、爆）
3. Web直販キャンペーン
■『オライリーアニマル柄クリアーファイル』プレゼント！
オライリー書籍の表紙を飾る下記5種類の動物が、それぞれのファイルにプリントされています。プレゼントは5枚1セットです。
動物5種：リャマ・トラ・ねずみふぐ・ジャーマンシェパード・ロリス猿
キャンペーンの一般公開（10月23日予定）に先立ち、BOOKCLUB会員のみなさまには本日より先行キャンペーンを実施します。
うーん、そんなに高くないけど、職場でギークっぷりを見せつつ使えるナイスなアイテム（爆）
ということで、１０月/11月の新刊の中から気になるものをピックアップ。
『詳解 MySQL』
Sasha Pachev 著
伊藤 直也、田中 慎司、吉川 英興 監訳
菅野 良二 訳
ISBN978-4-87311-343-2
定価3,360円
■ソースコードを読み解きながらMySQLを深部から理解する！■
オープンソースの価値は、ソースコードを読み解いて初めて引き出すことができます。MySQLの元開発メンバーによって書かれた本書は、MySQLのソースコードを読み解きながら、MySQLのパフォーマンスを引き出すためのノウハウを提供します。MySQLを理解したいデベロッパにとって、貴重かつ必須の内容です。
おお、はてな監訳！つか露出っぷりがすごいね、いつ仕事してんだ？
でも今の職場ではMySQLを使ってるのでこれは買う。
『Linuxシステム管理』
Tom Adelstein、Bill Lubanovic 著
千住 治郎 訳
ISBN978-4-87311-346-3
定価2,940円
■Linuxシステム管理に必要な知識を網羅！■
大規模システムのサーバとしてLinuxが広く使われるようになり、それに伴いLinuxに精通した管理者が求められています。そのような管理者が必要とする、Linuxシステムを管理運用する上での必須の知識がたくさんつまった一冊です。インストールから設定、管理、DNS/BINDのトラブルシューティング、メール設定、Webサーバ管理、データベース設定、
クラスタ管理、バックアップ方法などをカバー。ページ数を抑えながらも非常に濃い内容になっています。
ほんとはこれよりも『UNIXシステム管理 第3版〈VOLUME 1〉』『UNIXシステム管理 第3版〈VOLUME2〉』を手元に置いておきたいのだけど、２冊構成の上、なんといっても高いんだよね、まあそれだけの内容があるからなんだけど。なのでとりあえずこっちを持っておきたいなと。
でも『LinuxサーバHacks―プロが使うテクニック&ツール100選』『Linuxサーバ Hacks 2 ―コネクティング、モニタリング、トラブルシューティング』あたりとなんとなく内容がかぶりそうな予感もする。まあ中身を見てからかな。
ということで、今回もプレゼントはイタダキな予感（爆）
Category: UNIX, Server, Book, Diary | コメント＆トラックバック（0）
High Availability Linuxの日本語サイトは、、、
2007/10/05 21:52 posted by kunkichi
昨日のエントリの続き。
Open Tech Press | NTTら4社、オープンソース・クラスタウェアHeartbeatの日本語サイトを開設
NTT、NTTデータ先端技術（NTT-DI）、VA Linux Systems Japan（VA Linux）、NECは10月4日、オープンソースのクラスタウェア、Heartbeatの日本語サイトを共同で開設すると発表した（サイトオープンは5日）。
匆々たるメンツだね、これじゃ出る幕ないか、爆
ま、これを機に情報が整理されて活用事例が増えるのであればよし。
Category: UNIX, Server | コメント＆トラックバック（0）
High Availability Linuxの日本語サイトがオープン
2007/10/05 00:52 posted by kunkichi
おお！
明日の朝オープんってことは日本語コンテンツはもう大体できあがってるってことだよねぇ。
くそぅ、翻訳とかやりたかったぞ（笑）
Category: UNIX, Server | コメント＆トラックバック（0）
さくらで CakePHP
2007/09/17 03:21 posted by kunkichi
ちょっと作りたいアプリケーションを思いついたので、最近流行の CakePHP をさくらインターネットで使ってみようと。その時のメモ。
ちなみにうちのディレクトリ構成はこんな感じ。＋/home/example ・・・ ホームディレクトリ
｜
＋cake ・・・ cake ディレクトリ
｜
＋apps ・・・ CakePHPで作成するアプリケーション用ディレクトリ
｜ ｜
｜ ＋app1 ・・・ CakePHPで作成するアプリ1のappディレクトリ
｜ ｜ ｜
｜ ｜ ＋config, docs, libs, scriptsディレクトリとファイル
｜ ｜
｜ ＋app2 ・・・ CakePHPで作成するアプリ2のappディレクトリ
｜ ｜
｜ ＋config, docs, libs, scriptsディレクトリとファイル
｜
＋www ・・・ ウェブで公開されるディレクトリ（DocumentRoot）
｜
＋app1 ・・・ CakePHPで作成するアプリ1 の webroot
｜
＋app2 ・・・ CakePHPで作成するアプリ2 の webroot
｜
＋other ・・・ CakePHP以外のアプリを使う場合のディレクトリちなみに以下のサイトを参考にさせてもらいました。
ディレクトリ構成的には、
- 複数のアプリを同じcakeライブラリで使い回せるよう、cakeディレクトリを/home/UserName 配下に置く。
辺りのところは、I Love PHP さんとこで紹介されているのと同じポリシーなんだけど、
- セキュリティ的な観点から、appディレクトリはDocumentRoot（さくらの標準では、/home/UserName/www）からは見えないところに置く。DocumentRootに配置するのは、webrootディレクトリのみ。
- CakePHPで複数のアプリを作成するので、appディレクトリはアプリごとにコピーして配置。
- 同様に、webrootディレクトリもアプリごとにコピーして配置。各アプリへのアクセスは、http://www.○○○.com/app1/ みたいな感じでアクセス。
CakePHP以外のアプリをインストールする場合も同様のポリシー。
というところを追加してみました。
最近はホスティングもドメインも安くなってきたけど、それでもやっぱり余計な出費は抑えたい、一つの契約でいろいろやりたい、というお金がない人向けの設定（笑）。でも結構ニーズあるかと。
手順は以下。
ソースのダウンロードと展開
# cd ~/tmp
# wget http://cakeforge.org/frs/download.php/502/cake_1.1.17.5612.tar.gz
# tar zxvf cake_1.1.17.5612.tar.gz
# cd cake_1.1.17.5612
CakePHPライブラリの配置
# cp -r cake /home/example/.
アプリ用ディレクトリにappディレクトリを配置
# mkdir /home/example/apps
# cp -r app /home/example/apps/app1
公開ディレクトリにwebrootディレクトリを配置
# mv /home/example/apps/blog/webroot /home/example/www/app1
設定ファイルの編集
# vi /home/example/www/app1/index.php変更箇所は以下。CakePHPのマニュアルによると、ディレクトリのパスは’/abc/def’と指定するより、DS.’abc’.DS.’def’が推奨と書いてあるので、それに併せてます。
・・・
define('ROOT', DS.'home'.DS.'UserName'.DS.'apps');
・・・
define('APP_DIR', 'app1');
・・・
define('CAKE_CORE_INCLUDE_PATH', DS.'home'.DS.'UserName');
・・・
mod_rewriteの設定
# vi /home/example/app1/.htaccess
RewriteBase /app1
データベースの設定
# cd /home/example/apps/app1/config
# cp -pi database.php.default database.php
# vi database.php変更箇所は以下。
・・・
class DATABASE_CONFIG
{
var $default = array( 'driver' => 'mysql',
'connect' => 'mysql_connect',
'host' => 'mysqlXX.db.sakura.ne.jp',
'login' => 'UserName',
'password' => 'password',
'database' => 'UserName',
'prefix' => 'app1_');
var $test = array('driver' => 'mysql',
・・・
}
prefixをつけているのは、複数のアプリを作る場合にややこしくなりそうなので。
あ、そうそう、うちではビルドしたphp5で確認してます。さくら標準のphp4でも同様に動くかどうかは不明。
ではぼちぼち作っていきます。
Category: Programming, PHP, Server | コメント＆トラックバック（1）
2008/08/31/ 12:22
2008/08/25/ 21:10
2008/08/24/ 15:31
2008/02/19/ 23:52
2008/01/23/ 21:27