Home

技術系のメモと日々の雑感

Apache の MaxClients と KeepAliveTimeout の関係

昨日、Apache の設定を見直していた。
とあるサーバで負荷が上がって、その原因が Apache にあるのはすぐに分かった。
不思議だったのは、一昨日 MaxClients をデフォルトの 150 から 30 に減らしたのに、状況がさらに悪化したこと。
負荷上昇の原因は空きメモリ不足だと思ったのだが、違ったらしい。
その後、設定を眺めていると、KeepAliveTimeout を 30 にしていたことに気がついた。
ずっと前に、ロクに考えずに決めた値が残っていたのだ。
悪い予感がしたので Web で情報を漁ってみると、やはりこの 30 という値は問題外だった。
色々議論があるようだが、思い切って 1 に設定。
普通の(?)Web サーバならもう少し大きな値の方がいいかもしれない。
このサーバはちょっと特殊で、メモリの量が限られているのと、アクセスしてくるクライアントが KeepAlive を使ってない可能性が高かったからだ。
効果はバッチリで、スムーズにリクエストをさばけるようになった。
これでやっと安心して眠れる・・・。

Postfix が遅かったら delays を見よう

とあるサーバの Postfix が配送に時間がかかっていたのでログを眺めていたら delays という値があることに気づいた。

Aug 27 10:37:42 mail01 postfix/smtp[4363]: F1EA337B2D2: to=<hoge@example.com>, relay=xxxx.xxxxxxxxx.xxx[XXX.XXX.XXX.XXX]:25, delay=98, delays=0.01/0/14/84, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 754F720056)

4つの値が何を表しているのか分からなかったのでググってみると、ソースに含まれる RELEASE_NOTES に書いてあるとのこと。
といってもこれは過去のバージョンの話で、自分が使っている 2.5.6 のドキュメントの中では HISTORY の 2005/11/02 のところに記述があった。
って、そんな前からあったんだね・・・。

Completion of support for time stamps from different stages of message delivery.
The information is now logged as "delays=a/b/c/d" where a=time before queue manager, including message transmission;
b=time in queue manager; c=connection setup including DNS, HELO and TLS; d=message transmission time.

以下、delays の説明部分に書いてあるほとんどそのままだけど。
a は qmgr が処理する前の時間。
including message transmission ということなので、smtpd が外部からのメールを受信する時間とか、pickup がキューを走査する時間も含まれてるんだろうな。
b はそのものズバリ qmgr が使った時間。
c は次の配送先への接続の準備に使われた時間。
DNS に問題がないのにこの値が大きかったら、HELO が完了するまでに何かが起こってるということか。
d は配送に使われた時間なので、smtp が別のサーバに送ったり、local がスプールに保存するのにかかった時間だね。

NFS と TCP Wrapper

CentOS 5.0 の頃に設定した NFS の環境を CentOS 5.3 に移したらクライアントからつながらなくなってしまった。

mount: mount to NFS server 'XXX.XXX.XXX.XXX' failed: RPC Error: Authentication error

と、ありがちなメッセージしか返してくれない。
設定は 5.0 のをそのまま引き継いでいるんだけどな〜。
調べているうちに、hosts.allow で portmap だけ許可していたのを ALL で許可すると通ることが分かった。
ふ〜ん。
以前は portmap だけを許可すればよかったはずだけど、他にも TCP Wrapper で制限がかけられるようになったということか。
portmap は NFS だけが利用してるわけじゃないから、これが正しい流れなのかもしれないね。
さらに調べてみたら、原因は rpc.mountd だった。

portmap:XXX.XXX.XXX.XXX
mountd:XXX.XXX.XXX.XXX

rpc.mountd の指定がプロセス名と違ってるところが落とし穴だね。

keepalived(VRRP) 検証中

keepalived で VRRP の設定をしていたときに疑問に思ったのが state と priority の関係。
普通に考えたら priority だけでいいんじゃないのかなって思って調べてみたら、ソースに含まれる keepalived.conf.SYNOPSIS の state のコメントに「Start-up default state」と書いてあった。
そっか。
state って keepalived を起動したときの状態を決めるパラメータなんだね。
某有名サイトで、マスタとバックアップの両方の state を BACKUP に設定しているのを見かけたけど、これで納得。
マスタが切り替わった後、新たにバックアップ側を立ち上げ直すときにも priority だけ調整すれば済むからだね、きっと。
真似させてもらおう。
あと、garp_master_delay についての説明がぜんぜん見つからなかったけど、同じように keepalived.conf.SYNOPSIS を見たら「delay for gratuitous ARP after MASTER state transition」とのこと。
garp って gratuitous ARP のことだったのか。
スッキリした。

時々役に立つ iptab

iptables を叩くときに ipt[Tab] で補完しようとして気づくというのが定番らしいけど、自分もこのパターンで iptab に出会ってしまった。
CentOS だと perl-Net-IP パッケージをインストールしていると使えるコマンドだ。
実行すると

+----------------------------------------------+
| addrs   bits   pref   class  mask            |
+----------------------------------------------+
|     1      0    /32          255.255.255.255 |
|     2      1    /31          255.255.255.254 |
|     4      2    /30          255.255.255.252 |
|     8      3    /29          255.255.255.248 |
|    16      4    /28          255.255.255.240 |
|    32      5    /27          255.255.255.224 |
|    64      6    /26          255.255.255.192 |
|   128      7    /25          255.255.255.128 |
|   256      8    /24      1C  255.255.255.0   |
※以下略

という風に表示してくれるので、サブネットマスクやプレフィックスを調べるのにとても便利。
ただ、iptables の設定をしているときはやっぱり邪魔だね。
かといってパッケージごと削除してしまうのもアレだし。
で、こういうときに私がよくやるのはコマンドの頭にアンダーバーを付けるという手だ。
いわゆる自分ルールってやつだ。
この方法だと、万が一コマンド名を忘れてもアンダーバーでタブ補完すれば済むからね。
今回も _iptab にリネームして平和になったとさ。
めでたしめでたし。
まぁ、あまり人に勧められる方法じゃないけど・・・。