- - PR -
送受信が突然できなくなる？！(qmail)
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-05-05 23:41
こんばんわ。本当にお世話になります、そして、ありがとうございます。
休みも今日で終わり、明日から本格的に調整に入ります。 このGWは代替機が同じ状態にならないか不安で、休んだ気にならなかったです。 ぽんす様：
qmail-remoteを２０じゃなく、１０とか５とかにする方が現実的なんでしょうが、 １回で１０以上のリクエストは駄目の場合には対応できるけど、１０と設定した場合 本当に偶然にタイムアウト待ち状態が１０できたときに、また発生するかな？と考え、 １００という暴挙にでました。でも・・・ そうなんですよね。僕のやり方はとりあえず逃げ逃げ逃げで、何も解決はしてない。 一度１０に設定してみて、問題のドメインへ再送信をかけてみます。 ただ、タイムアウトは２０分から５分とかに減らしてみます。 タイムアウト待ちに２０分はやっぱ多いですよね。メールのサイズだって、 セイゼイ５MBくらいかな？って。昔は１MBでも大きいと思ってたんですが。 うちの社内の人間は平気で４０MBとか送るのでいつも怒ってます。 これは、社内で教育していく事を考えて行きます。 anight様： 「送受信」でなく「送信」です。もっと正確に伝えるように心がけます。 また何かありましたらご指摘下さい。 | ||||||||||||||||
|
投稿日時: 2005-05-06 00:04
送信待ちが発生した場合の、他のメールの送信への影響を軽減するという意味で、この対処は妥当だと思います。 逆に、concurrencyremoteを抑えるのは、
これを言葉通りに取ると、意味は無いかな、と考えます。 1通の配送毎にコネクションを張り直す qmail のスタイルそのものが拒否されていることになるからです。(ML等でそのドメイン宛ての大量のメールが発生すれば、いずれにしても短時間の内に多数の接続が行われてしまう) ※ まだ相手の反応が、接続放置(延々待ちが発生)ではなく、接続拒否(TCP RSTとか、SMTP 400番台エラーとか)なら救いがあったんですがね。 F/W 等の SPAM防止機能って、同時接続数と、接続試行回数とどちらを見るんでしょうね? 同時接続数が問題になるのなら、concurrencyremote を下げる意味も出てきますね。
いえ、qmail の並列配送の思想は、効率と信頼性にある筈です。 sendmail の遅い配送速度に不満を持った作者 ( djb ) が、効率を求めるために各配送プロセスが並行稼動できるように設計したという話があるようです。 また今回は、同一サイトへのメールに対して「まとめ送り」をしないのも原因となっているように思いますが、これはよくある質問の考えに基づいているようです。 まぁ、qmail と相手の F/W とが相性が悪いということでしょうか…。 そうなると、そのドメインに対しては、上で挙げた「よくある質問」にある、serialmail を使用するという対処策位しか思いつかないのですが…。 [ メッセージ編集済み 編集者: angel 編集日時 2005-05-06 00:11 ] | ||||||||||||||||
|
投稿日時: 2005-05-06 01:06
設定で制限はかけていないのでしょーか？ 上限を10MBとかに設定していれば3分〜5分くらいでいいかなと思いますが、 40MBでも投げなきゃならないのだとすると5分だとマージンがやや少なめ な気がします。
「1分間に20接続きたら拒否」みたいな設定ですか。それだとたしかに 同時接続数を下げても抜本的解決にはならないですね。 20接続でアウトとしているところに30宛先のメールを投げる場合、 同時10接続に下げておけば最初の約10宛先は成功、残り約20宛先は 次回以降にやり直し、というように進むはずですので同時100接続に 設定するよりはだいぶんマシだとは思いますが。 ・・・なんにせよ、かなり厳しい感じなので相手の設定を変えてもらう のがよいでしょうけど。 | ||||||||||||||||
|
投稿日時: 2005-05-06 01:57
こんばんは。明日は暦通り仕事ですが、土日までが GW だと、心の中で延長しています。
ところで、これまでの話の流れの中で一つ疑問なのですが…。 concurrencyremote を 100とか大きな値に設定するのは無茶なのでしょうか? 何せ qmail 自体 1998年に今の 1.03 が公開されてから、もう 7年経ってます。 もともと解説サイトでも pentium + 数十MBのメモリのマシンでの動作を説明しているような状態でしたから、標準の 20って、今は相当低い数値ではないかと思っているのですが…。 ※ 勿論、上げる必要がなければそのままで良いと思いますが。 問題は、接続先が多数の同時接続を受けた時の影響、ですが、問題になるのは総流量(もしくは帯域や総接続時間)であって、接続数では無いと思うのですが。 ※ え? 多数の接続を捌けないソフトがあるかも? …なんて心配は必要ないですよね? | ||||||||||||||||
|
投稿日時: 2005-05-06 09:37
最近ではウィルススキャンを行うMTAが途中でかんでたりしますので 大きな添付ファイル付きメール送信を許す運用をしているのであれば タイムアウト値はスキャン時間も考慮に入れた方が良いと思います。 そうしないとスキャン中に切断なんてことにもなりかねません。 ただ、これも使用しているウィルススキャンソフトやらアプライアンス製品やら によって仕様がまちまちですので（受け取っておいて後でスキャンするものや SMTP通信中にスキャンするものなど）悩ませるところではありますが。
うーん、MTA周りのチューニングってトータルバランスですから (angelさんが他の投稿でも書かれてますが)concurrencyremoteの値ひとつをとって 大きい、小さいと言っても意味の無いことだと私は思います。 どっかでウェイトがかかっている方がバランスよかったりとか 
リモート全体の数って考えると20は低い気がしますが今回のように 条件によっては1ドメインに対する上限という可能性もあることを考えると あながち低くは無いのではないかと思いますが。 意欲的に更新されているPostfixの1ドメインに対する配送上限て標準で20ですよね？ 文面からするにハードウェアの性能面を言っているのかもしれませんが そんなに世の中すべてのサーバって刷新されているんでしょうか？ 結構古いのが元気でいると思うんですけど。 どちらかというと問題は、qmailではリモートっていう大きなくくりの 制限となってしまっていることだと思います。 なのでconcurrencyremoteを大きく設定しておいて 1ドメインに対する上限を設定出来るパッチを適用して それでコントロールするのが良いのかもしれませんねぇ。
まったくその通りだと思います。 
ただ、実装としては「一定時間における同一リソースからの接続数」って方が 多い気がしますね。 | ||||||||||||||||
|
投稿日時: 2005-05-06 10:00
業務端末に限って言えば、私の周囲ではいい加減 Pentium3 以上のマシンしか残ってないもので…、その感覚で書いていたのは確かです。 それと、受け側の性能についても考慮すべきかと考えたのですが、受け手に関しては元々世界中どこからどれだけメールが来るかは不定ですし、接続数は自身で調節できますから、話がまた別かなと思っていました。
これは私も感じたことはあります。 なにせ、1 ドメインでの送信トラブルが、今回のように全体に影響する恐れがありますから。 ※…そう考えると、「ソフト自体の質に問題があるか、プロトコルや設計レベルで問題があったり、難解な点があるものと感じていますが…、少なくとも qmail には思いあたりません。」という最初の私の書き込みは正しくないですね。 かつては docomo 宛メールで、docomo 側が qmail からの並列送信を捌ききれないということがあったとも聞いていますし…。 どこかにパッチありませんかね? ※ まとめ送りを実装するよりは簡単なはずなので、誰か作っていないかなぁ… [ メッセージ編集済み 編集者: angel 編集日時 2005-05-06 10:04 ] | ||||||||||||||||
|
投稿日時: 2005-05-06 10:47
おはようございます。
anight様、angel様、ぽんす様 色々とご助言ありがとうございます。 もう皆様の書き込みには、ついて行ってない状況です（T_T); 少しづつ理解できればいいんですが・・やれるだけ頑張ります。 とりあえず以下の設定を加える事を考えます。 １、timeoutremote を １０分に変更。 ２、queuelifetime を ３日に変更。 ３、concurrencyremote を １００に変更 （１）は大きなファイルは送らせないという運用で１０分もあれば良いだろうという判断です。 相手によっては、未だに２・３MB強でも送れない所もあり、その都度大きなファイルは送らないでと最悪の場合は、filesend toを使ってねとかCDで送ってねとかそう言う方法にしていました。 なんで、できるだけ早くタイムアウトを起こしてくれるとqmail-remoteも残りにくいだろうという事です。 （２）は、どうせ駄目な状態になれば早いうちにユーザーに送れませんでしたよと通知してあげるほうが業務に支障がないかな？と考えました。７日も経ってから駄目といわれても困りますしね。 ３日にしたのは、もし相手サーバーがトラブルを抱えてても大体２・３日あれば復旧するだろうという希望の数値です。 （３）は、qmail-remoteが何らかの原因で増えた場合、レンジを広くして他メールへの影響に及ぶのを極力長い時間逃げれるかな？という事で１００にしました。 ただ、今回の件は、一度１回１０にしてどうなるかみてみます。 本当に皆様ありがとうございました。 | ||||||||||||||||
|
投稿日時: 2005-05-06 13:04
参考だけ。
qmailの同一ドメインへの配送最大多重度制限機能を追加するパッチ がチラっとあったので私は書きました。 私は無理にqmailでやる必要もないのでPostfixなりにしてしまいますがね。 (いやsendmailやeximでもいいのですけどね。3つともRedhat EL4には入ってるし) qmailにこだわることとパッチをあてて仕様を変えることは 私の中では相反することですので実装しているものを使うって感じです。 上に挙げたものが実装しているかは知りませんが。。。 まあ、最近はお客様がいい加減な雑誌に踊らされてMTA指定したりするので 選択の自由なんかありませんが 
| ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。