- - PR -
postfixのセッションについて
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-06-21 17:53
postfixのSMTPセッションについてお聞きしたいことがあります
有識者のみなさまからご教授いただければと思います。 ＜構成＞ 現在ウイルスチェックサーバをメールゲートウェイに設置し2台同じコンフィグにて冗長化し、前段LBにて振り分けるという構成にしています。 このサーバのMTAにpostfixを使用し、受け付けるメールはexample.co.jpと*.example.co.jpのみ内部ドメインサーバへ配送し、内部からのメールはすべての宛先へ配送する設定になっています。またSPM対策にアドレス検証の問い合わせの際に遅延を30秒入れています。 ＜経緯＞ ある日1台を止めて残りの1台のみで稼動しているときメールが1時間ほど遅延していると言われ調査を実施、原因を切り分けるためpostfix,LBのログを調査、前段LBのヘルスチェックのログから頻繁にdownステータスがでていることが判明（downの際はsmtpセッションを転送しなくなる、ヘルスチェックは25番ポートへ実行）しかしなぜセッションが張れなくなるのかという根本的な問題が解決しません。 ＜お聞きしたいこと＞ 原因はセッション関係のパラメータかSPM対策のパラメータにあると考えているのですが今回の現象に関係がありそうなパラメータをご存知のかた教えていただけますでしょうか 長文で申し訳ありません 有識者のかたのご教授をお願いいたします。 | ||||||||||||
|
投稿日時: 2006-06-21 20:52
こんばんは。
postfixのバージョンは？ ウィルスチェックには何をお使いですか？ postfixのコンフィグを提示できますか？(postconf -nの結果)
この時に、postfixのログには何か普段と違うログは出力されてませんでしたか？ | ||||||||||||
|
投稿日時: 2006-06-22 15:20
to:zume様 返信ありがとうございます
postfixバージョン postfix-2.2.8-4.rhel3 ウイルスチェック TrendMicro社 InterScanMessagingSecuritySuite postconf -nの出力 2bounce_notice_recipient = d-bounce@（FQDN) address_verify_poll_delay = 30s alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases bounce_queue_lifetime = 3d command_directory = /usr/sbin config_directory = /etc/postfix content_filter = ****:localhost:10025 daemon_directory = /usr/libexec/postfix debug_peer_level = 2 default_process_limit = 200 disable_vrfy_command = yes fallback_relay = ****@**.**.**:25 #←エラーメールの配送先 html_directory = /usr/share/doc/postfix-2.2.8-documentation/html inet_interfaces = all mail_owner = postfix mailbox_size_limit = 0 mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man maximal_backoff_time = 14400 maximal_queue_lifetime = 7d message_size_limit = 51380224 minimal_backoff_time = 900 mydestination = (FQDN), localhost.**.**.** mydomain = **.**.** myhostname = （FQDN) mynetworks = ***.***.0.0/16, ***.**.0.0/16, 127.0.0.0/8, ***.***.0.90/32 newaliases_path = /usr/bin/newaliases.postfix notify_classes = resource,software queue_directory = /mqueue/postfix readme_directory = /usr/share/doc/postfix-2.2.8-documentation/readme relay_domains = $内部ドメイン1, $内部ドメイン2, $内部ドメイン3, $内部ドメイン #←リレーを許可するドメイン sample_directory = /etc/postfix sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtpd_banner = （FQDN） ESMTP smtpd_helo_required = yes smtpd_recipient_limit = 1000 smtpd_sender_restrictions = permit_mynetworks, check_sender_access hash:/etc/pos tfix/sender_access, reject_unknown_sender_domain, reject_unverified_sender smtpd_timeout = 600s unknown_local_recipient_reject_code = 550 長文で申し訳ありません。追加でmaillogを調査しているところでございますが ひとつ気になる箇所が見つかりましたのでご報告させていただきます。 lost connection after CONNECT from unknown[***.***.***.***] という出力が頻繁にでているような気がします。通常正常に配送しているログですと connect from unknown[***.***.***.***] 〜 disconnect from unknown[***.***.***.***] と出力されるのですがlost connection〜の意味をぐぐってみたのですがなかなかでてきませんでした。やはりコネクション関連に原因があると思っているのですが..... ご存知のかたいらっしゃいましたら教えていただけますでしょうか | ||||||||||||
|
投稿日時: 2006-06-23 15:33
＞lost connection after CONNECT from unknown[***.***.***.***]
これはSMTPセッションを張った後、QUITでは無い何かの原因でコネクションを切った場合に出ます。 $ telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mail.example.com ESMTP Postfix (Ctrl+]で抜ける) telnet> quit とやると、上記ログが出ます。 PortScan とかですかね。 LBからのヘルスチェックとかPortScanとかでTIME_WAITなセッションが多く残っている可能性もあると思います。 OS側のセッション保持時間を短くするとかを試してみてはいかがでしょう。 (OSが書いてないので、やり方までは書けませんが…) [ メッセージ編集済み 編集者: かつ 編集日時 2006-06-23 15:35 ] | ||||||||||||
|
投稿日時: 2006-06-23 20:51
こんばんは。
postconf -nの出力結果からは、postfixが１時間も延滞させるような設定は されてませんね。 という事で、疑えるのはやはりLBかInterScanMSSですかね。 で、（メールが延滞とあるので、違うとは思いますが）可能性として。。。 InterScanMSSで自動アップデートを利用されてませんか？ Linux+InterScanの組み合わせだと、その自動アップデート後にサービスが上手く リロード出来ずにSMTPのセッションが張れない状態に陥る事が結構ありました。 ※手動でアップデートしても駄目な時は駄目ですけど ※この現象はpatch4で解消されたようです http://esupport.trendmicro.co.jp/supportjp/viewxml.do?ContentID=11379 | ||||||||||||
|
投稿日時: 2006-06-30 10:38
遅くなり大変申し訳ありません。
確認したところPatch4を適応していました。情報ありがとうございます。
ありがとうございます。現在Spamなどが大変多く、lost connection after **** という出力が頻繁にログに出ています。本当はPostfixの受け側でなにか対策を考え なくてはいけないのですが...。（spamは以前からも頻繁に来ていたので今回のセッションのことにはあまり関係がないのでしょうか？）
TIME_WAITやその他CLOSE_****などのセッションが残っていると影響があるのでしょうか？（セッションを受付ずらくなるとか）またnetstat -an | grep :25などで確認すると 受信の:25のソケット数が100前後あることがわかりました。未熟で申し訳ありませんがデフォルトの default_process_limit = が100だったと認識しておりますが、その数はソケットの開ける数とイコールなのでしょうか？もしその場合、ソケットを100開いた状態で次のセッション要求が届くとソケットが空くまで:25で待たされ、時間がすぎるとタイムアウトし、一定時間後再送→同じく待たされタイムアウトの繰り返しで遅延しているのではと自分では考えています。かなり妄想の域をでないのですがこの場合、default_process_limitの値を少しずつ高くしていき様子をみたいと思っています。 上記の考え方について有識者の方々のご指南をいただければ幸いです。 | ||||||||||||
|
投稿日時: 2006-07-07 14:01
＞TIME_WAITやその他CLOSE_****などのセッションが残っていると影響があるのでしょうか？
あると思います。ＯＳ側のパラメータで同じプロセスで受け付ける事の出来るセッションは上限が設定されていると思います。 TCP通信では、セッションを開始する際の負荷が結構高いので、なるべくその負荷を軽減する為にTIME_WAIT状態を数分維持して再利用しようとします。 これがトラフィックの多いサーバ（Webサーバとかメールサーバとか）だと悪影響となり、新規接続が出来なく事があります IMSSだと、トレンドマイクロ社からの資料でこの辺のOSパラメーターを変更する様に書いてありませんか？（何の資料だったかな？） 前にも書きましたが「y-onoさんのOS環境が書いていない」ので、変更方法が書けません。 | ||||||||||||
|
投稿日時: 2006-07-08 20:02
TIME_WAIT状態は、「漂流するパケット」への対策として設けられて いるものです。先にTCP接続を終了した側（サーバ側・クライアント側 という役割とは関係ない）は一定時間、必ずこの状態に入ります。 とりあえず、「使用禁止期間」とでも思っておけばいいでしょう。 「使用中」というわけではないので、（何千も溜まっている、という ようなことが無い限り）ほとんど影響はありません。
TIME_WAIT以外でその数だとすると、かなり多いですね。 IMSSのせいかな？ ・そもそも秒間接続数が多い ・接続元が遅い ・自サーバの処理速度不足で、処理待ちが溜まっている のどれなのか、突き止めることが先決でしょう。
そういうことは起こります。 ですが、単にプロセス数の上限を上げればいいというものではなく （下手をすると現在より更に悪くなる可能性もある）、まずは 現状を把握することです。 | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。