― MozillaZine.jp フォーラムは Mozilla 製品に関する情報交換の場です ―



All times are UTC + 9 hours

新しいトピックを投稿する トピックへ返信する  [ 27 件の記事 ]  ページ移動 1, 2  次へ
作成者 メッセージ
投稿記事Posted: 2011年1月02日(日) 07:35 
debain/squeeze 上で thunderbird (icedove) 3.1.7を使用しています。
tb のアカウント/接続サーバ毎ではなく tb 全体での最大同時接続数の
詳細について教えてください。

現象:
 thunderbirdの総接続数が 50に達すると新規接続ができなくなる。

知りたいこと:
 ・thunderbird 全体での最大同時接続数が 50というのは正しいのか?
  ※ OS側の設定の可能性も否定できていません。
 ・最大同時接続数を増やすための設定方法
  ※ about:config やコンパイル時設定など

経緯:
テスト用や用途別に webmailのアカウントを適当に作ってたら無駄に数(30前後)が
増えたので、tbでまとめて管理できるようにしようと思い設定(imap)を行いました。
普段使用する際には何の問題もないのですが、複数のアカウントのフォルダを
短時間に 10前後次々に開こうとすると、途中からマウスポインタが
busy状態のままになりフォルダを開くことができなくなります。
tb自体が固まるというわけではありませんが、それ以降新しいフォルダを開くことが
できなくなります。
数分から数十分の間隔を開けると、また新しいフォルダを開くことができるように
なりますが、数個のフォルダをひらくと再度開けなくなります。
それで、ふと思いついて
 netstat -tpn | grep 993.*icedove | wc -l
してみたら、現象が発生した時の結果が常に 50なのです。
web で検索してみたのですが、thunderbird 全体での最大同時接続数に関する
情報を見つけることができませんでした。
コマンド結果から推測した thunderbird の最大同時接続数は 50というのは
正しいのでしょうか。
現状、thunderbirdを再起動すれば問題なく新規フォルダも開けるので
運用で回避という感じですが、可能なら最大同時接続数を増やしたく思っています。
about:configの設定、もしくは、ソースコード中のどこかの変数を
変更してリコンパイルすれば可能などの情報をお持ちの方がおられるなら、
教えていただけるとありがたいです。

OS: debian/squeeze
UA: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101214 Lightning/1.0b2 Icedove/3.1.7
確認コマンド:
 netstat -tpn | grep 993.*thunderbird | wc -l

現状の設定:
 30前後のアカウント(imap)を tbに設定。
 アカウントのサーバ設定:
  mail.server.serverXX.check_new_mail -> true が 10前後/false が 20前後
  mail.server.serverXX.check_time   -> 15 から 60 に分散
  mail.server.serverXX.max_cached_connections -> 3 から 5

 接続サーバ (imaps)
  imap.googlemail.com
  imap.mail.yahoo.com
  imap.aol.com


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2011年1月02日(日) 12:06 
オフライン
Administrator

登録日時: 2005年9月02日(金) 00:59
記事: 1762
よくわからないんですが、私の場合は以下の設定内容(デフォルト値)になっていて
mail.imap.max_cached_connections=10
mail.server.serverXX.max_cached_connections=5
imap接続はサーバ毎に5個、10サーバ分の接続ができるという感じなのでしょうか、見た目は50接続分が最大のような感じがします。
フォルダ移動ごとに新たな接続としてログイン情報を送っているようなので、ひとつのimapサーバに対するアカウントが多く、フォルダに対するアクションで接続が増えるということなら、mail.server.serverXX.max_cached_connections の方を増やしてやれば良いのではないかと想像するのですが....
ただし、サーバ側の接続許可数やThunderbirdに割り当てられるメモリやスレッド数の制限で待ちが発生しているのならわからないですが。

試してみたところ、
mail.server.serverXX.max_cached_connections=1 では1接続しかせず、フォルダ移動して戻っても再度読み直しをしているようでマウスカーソルがグルグル回っています。
20に設定(imapのフォルダは10個しか有りませんが)すると最初だけ待たされますがフォルダの移動によるメールの表示(の切り替え?)は速くなります。
(フォルダが30個有れば30を指定する必要があるかもしれません)

こんな感じで上の二つのパラメータを調整して試してみてはいかがでしょうか。
ただ、これは接続状態のキャッシュだと思うのでフォルダの内容を読みきらないうちに移動させることを素早く繰り返した場合は設定変更の効果の有無はわかりません。

--
Windows 7 Enterprize
Thunderbird 3.1.7


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年1月02日(日) 13:23 
返答ありがとうございます。

問題点がうまく伝わらなかったようなので、
頂いた返答に沿って、再度問題点を書いてみます。

現在、imapのアカウントを 30 前後設定しています。
※このアカウント数がすでにレアケースな気もしますが、
 アカウント数に関わらず今回の現象は発生すると考えています。

回答いただいた、mail.imap.max_cached_connectionsや、
各アカウントの mail.server.serverXX.max_cached_connectionsを
どのような値に設定しても、各アカウントの接続数の合計が
50を超えることができません。

最初の投稿で書いたように、thnderbirdの使用している imap 接続の合計(netstatで確認)が
50の時に新規接続(フォルダ閲覧)を受けつけなくなるのです。
※imapの場合だけではなく、htmlメールの場合に thnderbird が画像などを
 読み込むために行う http接続も最大同時接続数に含まれるようです。
 つまり、imap、http含めた 総接続数が 50を超えることができません。

この状況から thnderbird 全体での最大同時接続数が 50なのではないかと推測しています。
反証や関連する情報をいただけるとありがたいです。


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2011年1月02日(日) 14:44 
オフライン
Administrator

登録日時: 2005年9月02日(金) 00:59
記事: 1762
あぁ、そういうことでしたか。
それなら違いますね、TCPViewで見ると うちはThunderbird単体のpop,imapで接続数50を超えています。

最大接続数ということで検索してみると、Thunderbird3.xはimapサーバへの接続が多すぎると書かれているものもあるんですが、もしかしたら接続数が多すぎてエラーを起こしているのに何かの理由でダイアログが表示されないまま停止していてタイムアウトになってからフォルダ移動が可能になるという感じではないでしょうか。
逆にサーバ接続数5は多すぎるので、2に設定してエラーを起こさなくなったという記事を見かけました。

見ていると、フォルダを移動した後でも先の接続を維持したままの時間が長いですが、アイドル状態を切断するパラメータはわかりません。接続数を減らせば強制切断するのかもしれませんが...(1に設定して移動できていたので)

2つのパラメータの値を小さくして試してみるのも有りかも。


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年1月02日(日) 14:44 
オフライン
Administrator

登録日時: 2005年6月23日(木) 23:29
記事: 2743
お住まい: 東京
whoami さんが書きました:
最初の投稿で書いたように、thnderbirdの使用している imap 接続の合計(netstatで確認)が
50の時に新規接続(フォルダ閲覧)を受けつけなくなるのです。
※imapの場合だけではなく、htmlメールの場合に thnderbird が画像などを
 読み込むために行う http接続も最大同時接続数に含まれるようです。
 つまり、imap、http含めた 総接続数が 50を超えることができません。

この状況から thnderbird 全体での最大同時接続数が 50なのではないかと推測しています。
反証や関連する情報をいただけるとありがたいです。

Thunderbird 全体での同時接続数となると network.http.max-connections だと思います。
ただ、初期値では 50 ではなく 30 のはずですが。
ネットワーク周りの設定は network.http.* に集約しています。

_________________
[Desktop] Windows 10 Pro 22H2 (64bit) / Intel Core i7-2600 / Nvidia GeForce GTX 1650 GDDR6 / 32 GB Memory
[Laptop] Windows 10 Pro 22H2 (64bit) / Intel Core i5-520M vPro / Intel HD Graphics / 8 GB Memory
[Android] Android 13.0 (arm64) / Xperia 5 III (XQ-BQ42)
常用環境: Firefox ベータ版、リリース版 (Win64 x86-64, Android), Thunderbird ベータ版、リリース版 (Win64 x86-64)
テスト環境: Firefox (ESR, Nightly, Win64 x86-64, Android)

Cai/1.0 (Homo sapiens; N; Homo sapiens chemist; male; rv:0.0.4.2+)
-- いつまでたっても nightly


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年1月02日(日) 15:07 
オフライン
Administrator

登録日時: 2005年9月02日(金) 00:59
記事: 1762
Cai さんが書きました:
Thunderbird 全体での同時接続数となると network.http.max-connections だと思います。
ただ、初期値では 50 ではなく 30 のはずですが。
あれ? うちは30になってますが pop,imap,http合わせて50以上接続してますね。


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年1月02日(日) 16:04 
kiyo4_kさん、Caiさん、ありがとうございます。

Cai さんが書きました:
network.http.max-connections だと思います。

この値を 30, 50, 100と試してみましたが
相変わらず総接続数が 50を超えることができません。
どの値でも 50のまま変化がありません。

kiyo4_k さんが書きました:
あれ? うちは30になってますが pop,imap,http合わせて50以上接続してますね。

あー、ちょっと安心しました。network.http.max-connectionsが原因だったとすると、
自分の環境を疑わないといけなくなってしまうので。


kiyo4_k さんが書きました:
もしかしたら接続数が多すぎてエラーを起こしているのに

この辺りを考慮して、mail.server.serverXX.max_cached_connectionsの値は
よく使用するアカウントを 3個選んで "5"、それ以外は "3"にしています。
この設定だと、同じプロバイダの異なるアカウントから、
1つの imap サーバへの接続が 10を超えるようなことはほぼないようです。
また、過去に接続数超過のエラーを見たことはあるので、エラーダイアログが
停止しているわけではないと思っています。

なんか、netstatを 1分おきくらいに実行して眺めてみると、
CLOSE_WAITになってる接続のタイムアウト待ちになってる感じです。
この CLOSE_WAITな接続が 1ついなくなると、新しいフォルダを 1つ開けるようになるけど、
CLOSE_WAITな接続が閉じるのに、だいたい数分から20分くらいかかっているように見えます。


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2011年1月02日(日) 17:31 
オフライン
Administrator

登録日時: 2005年9月02日(金) 00:59
記事: 1762
whoami さんが書きました:
なんか、netstatを 1分おきくらいに実行して眺めてみると、
CLOSE_WAITになってる接続のタイムアウト待ちになってる感じです。
この CLOSE_WAITな接続が 1ついなくなると、新しいフォルダを 1つ開けるようになるけど、
CLOSE_WAITな接続が閉じるのに、だいたい数分から20分くらいかかっているように見えます。
数分から20分くらいっていうのは長すぎると思いますけど、うちでmail.server.serverXX.max_cached_connections=10 の時にはCLOSE_WAITの表示さえ出ません。数に余裕があるのでずっと接続しっぱなしってことでしょうか。
私が接続しているimapはGmailなので同じはずですよね。
もうひとつsoftbankのimapも有りますが、これはルーターのバグで今は再起動するまで接続を拒否されているので試せません。

アカウントが多いということなので 3でも多いのかもしれません。逆に mail.server.serverXX.max_cached_connections=1 という風に制限を加えてみてはどうでしょう。強制切断して新しい接続を行うような気がします。


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年1月02日(日) 17:58 
kiyo4_kさん、長時間お付き合いいただき本当にありがとうございます。


えーと、問題点を少し分けてみると、
 1. thunderbird 全体での最大同時接続数が 50から変更できない。
 2. thunderbird 全体での最大同時接続数に達した場合に
  新規接続ができない(新規フォルダが開けない)。または、長時間待たされる。
になると思います。

んー、1.ができれば 2.はあまり問題じゃなくなるんだけどなぁ。

kiyo4_k さんが書きました:
私が接続しているimapはGmailなので同じはずですよね。

imap 接続先は、
  imap.googlemail.com:993
  imap.mail.yahoo.com:993
  imap.aol.com:993
で、アカウント数も だいたい 10ずつくらいです。

確認してみたら、長期間 CLOSE_WAITな状態になるのは、
imap.aol.com と imap.mail.yahoo.com との接続で、
たしかに、imap.googlemail.com ではなりません。

で、上記の 2 について少し確認したいのですが、
thunderbirdの動作として正しいのは、
「最大同時接続数に達した場合は、古い接続を切断して新規接続をする」
ということでいいんですよね。
これが正しいなら、「長期間 CLOSE_WAITな状態」になってしまう、
imap.aol.com、imap.mail.yahoo.comの imapサーバが 2.の原因ってことになる、のかなぁ。
AOLとYahoo両方が悪いっていうのは考えづらいような気もするし。

kiyo4_k さんが書きました:
mail.server.serverXX.max_cached_connections=1 という風に制限を加えてみてはどうでしょう。

これは、後で試して報告します。


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2011年1月02日(日) 18:44 
kiyo4_k さんが書きました:
mail.server.serverXX.max_cached_connections=1 という風に制限を加えてみてはどうでしょう。

試してみました。

全アカウントの mail.server.serverXX.max_cached_connections=1 にして
最大同時接続数に達した場合:
 imap.googlemail.com -> 新規接続可能
 imap.mail.yahoo.com -> 新規接続不可
 imap.aol.com     -> 新規接続不可

全アカウントの mail.server.serverXX.max_cached_connections を "3" または、"5" にして
最大同時接続数に達した場合:
 imap.googlemail.com -> 新規接続可能
 imap.mail.yahoo.com -> 新規接続不可
 imap.aol.com     -> 新規接続不可

すみません、私が確認をミスっていたようです。
imapという括りでまとめて考えていたせいか、最大同時接続数に達した場合には
全アカウントで新規接続不可だと思い込んでいましたが、
あらためて確認してみたら、gmailは大丈夫で、Yahoo、AOLはダメというのが、
正確な結果のようです。

となると問題は、「長期間 CLOSE_WAITな状態」になってしまう AOLとYahooに
対して設定で回避可能か、可能ならばその設定値は?、というところですか。

ともかくも、一歩前進です。ありがとうございます。


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2011年1月02日(日) 18:57 
オフライン
Administrator

登録日時: 2005年9月02日(金) 00:59
記事: 1762
whoami さんが書きました:
確認してみたら、長期間 CLOSE_WAITな状態になるのは、
imap.aol.com と imap.mail.yahoo.com との接続で、
たしかに、imap.googlemail.com ではなりません。

で、上記の 2 について少し確認したいのですが、
thunderbirdの動作として正しいのは、
「最大同時接続数に達した場合は、古い接続を切断して新規接続をする」
ということでいいんですよね。
1のほうはわからないですが、
「最大同時接続数に達した場合は、古い接続を切断して新規接続をする」というのは実際にmail.server.serverXX.max_cached_connections=1という設定でフォルダが切り替わっていくので そういう動作なのだろうと考えてます。接続が1しかないので古い接続をクローズして切断するしかないと思うので。
ただ、私の接続先はGmailなので下に書いた予想が邪魔するとなれば失敗しそうですね。

whoami さんが書きました:
これが正しいなら、「長期間 CLOSE_WAITな状態」になってしまう、
imap.aol.com、imap.mail.yahoo.comの imapサーバが 2.の原因ってことになる、のかなぁ。
AOLとYahoo両方が悪いっていうのは考えづらいような気もするし。
もしかすると、imap.aol.com、imap.mail.yahoo.comの imapサーバの動作は正しいかもしれません。過去の経験からの想像ですが、
(smtpに限ったことだったかもしれませんが...)GmailがQUITの後に応答を返さずに接続を切断してしまうというRFC違反のバグが有って、Thunderbirdは このようなRFC違反の動作をリカバーするように作られているような気がするからです。
つまり、「応答を無視して相手からの切断により終了しようとする」ってことで、imap.aol.com、imap.mail.yahoo.com はちゃんと応答を返して手順により切断するという正しい動作を行おうとするが、Thunderbirdは相手の切断を待ち続けるだけ....という動作になっているんじゃないかなぁ...と予想しています。CLOSE_WAITが消えるのは相手サーバの応答待ちタイムアウトの結果かもしれません。


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年1月02日(日) 19:26 
オフライン
Administrator

登録日時: 2005年9月02日(金) 00:59
記事: 1762
whoami さんが書きました:
全アカウントの mail.server.serverXX.max_cached_connections=1 にして
最大同時接続数に達した場合:
 imap.googlemail.com -> 新規接続可能
 imap.mail.yahoo.com -> 新規接続不可
 imap.aol.com     -> 新規接続不可

全アカウントの mail.server.serverXX.max_cached_connections を "3" または、"5" にして
最大同時接続数に達した場合:
 imap.googlemail.com -> 新規接続可能
 imap.mail.yahoo.com -> 新規接続不可
 imap.aol.com     -> 新規接続不可
あら? 同じでしたか...
「Thunderbirdは相手の切断を待ち続けるだけ」ですかね。これ、ちょっと痛いですね。

whoami さんが書きました:
あらためて確認してみたら、gmailは大丈夫で、Yahoo、AOLはダメというのが、
正確な結果のようです。

となると問題は、「長期間 CLOSE_WAITな状態」になってしまう AOLとYahooに
対して設定で回避可能か、可能ならばその設定値は?、というところですか。
う~ん....Gmailで問題ないのに、他のimapで問題が発生するっていうのは、ThunderbirdのimapってGmailに特化してるんですかね。

変更可能なパラメータで言うと
network.http.keep-alive.timeout
mail.server.serverXX.timeout
mailnews.tcptimeout
ぐらいが関係有るのか無いのか、ですかね。

ここまでくると内部動作に詳しい人の応援が必要な感じです。


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年1月02日(日) 20:41 
kiyo4_k さんが書きました:
GmailがQUITの後に応答を返さずに接続を切断してしまうというRFC違反のバグが有って、
Thunderbirdは このようなRFC違反の動作をリカバーするように作られているような気がするからです。

kiyo4_k さんが書きました:
「Thunderbirdは相手の切断を待ち続けるだけ」ですかね。これ、ちょっと痛いですね。


ありゃ、もしかしてこれ、↓
kiyo4_k さんが書きました:
となると問題は、「長期間 CLOSE_WAITな状態」になってしまう AOLとYahooに
対して設定で回避可能か、可能ならばその設定値は?、というところですか。

は早とちりの可能性があるってことですか?
えーと、thunderbirdの imap クライアントとしての実装が RFC違反の
gmailを前提にしているために、まともに RFC準拠の実装しているであろう
AOL、Yahooで不具合となっている可能性があるということですよね。
んー、mail.server.serverXX.is_gmailみたいな設定もあるからなんとなく安心してたんですが。


kiyo4_k さんが書きました:
あら? 同じでしたか...

ちょっとあせって確認、投稿しちゃったところがあるので、少し補足します。

全アカウントの mail.server.serverXX.max_cached_connections=1 にした時の
確認方法ですが、全アカウント合計が 30くらいで、最大同時接続数が 50なので、
当然、最大同時接続数に足りないので、あちこちで html メールを開いて
最大同時接続数にしました。
ただ、httpの方が接続確立->切断までの時間が短いので、確認結果に少し不安は残ります。
「AOL行けたっ」と思ったら、最大同時接続数以下になってたみたいなことはあったので。

あと、厳密な割合まではわかりませんが、傾向として Yahooの方が
CLOSE_WAITで残りやすい感触です。
Yahooは imap idleサポートしてなくて、AOLはサポートしてるのが
関係あるのか、ないのか...


kiyo4_k さんが書きました:
う~ん....Gmailで問題ないのに、他のimapで問題が発生するっていうのは、
ThunderbirdのimapってGmailに特化してるんですかね。


今回ほど詳しく確認したわけじゃないけど、前に会社で courier imapサーバ使用してた
時期があって、特に問題なく使用してたんですけどねぇ...

kiyo4_k さんが書きました:
ここまでくると内部動作に詳しい人の応援が必要な感じです。

確かにどなたかにご登場いただけるとありがたいですが、
現状、あまり切羽詰っているわけでもないので、教えていただいたパラメータを
試したりしながら気長にやろうと思います。

今日はもう終りにしようと思いますが、なにか進展があれば書き込みますので
またよろしくお願いします。ありがとうございました。


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2011年1月02日(日) 23:30 
オフライン
Administrator

登録日時: 2005年9月02日(金) 00:59
記事: 1762
whoami さんが書きました:
ありゃ、もしかしてこれ、↓
whoami さんが書きました:
となると問題は、「長期間 CLOSE_WAITな状態」になってしまう AOLとYahooに
対して設定で回避可能か、可能ならばその設定値は?、というところですか。
は早とちりの可能性があるってことですか?
えーと、thunderbirdの imap クライアントとしての実装が RFC違反の
gmailを前提にしているために、まともに RFC準拠の実装しているであろう
AOL、Yahooで不具合となっている可能性があるということですよね。
んー、mail.server.serverXX.is_gmailみたいな設定もあるからなんとなく安心してたんですが。
GmailにはRFC違反が有るらしいんですが、4年も前のことでsmtpに限ってだったかimapもだったかよく覚えていないんですけど、動作とIPの接続状態を見ていてなんとなく これも同じ状況でAOL、Yahooでバグが発症しているのかなぁなんて思いました。
IP接続の状態を見ていると、Gmailの場合はどんどん切断と接続を繰り返していて速すぎて見えないのか、または同じ接続を再利用しているような表示に見えます。Thunderbirdでフォルダを移動するときに、「接続しています」とか表示されているのにIP接続の状態表示が変化せずに進んでいくので そんな風に感じるんです。
でも、見た目だけではわかんないんですけどね。

.is_gmailなんてパラメータが有るんですね、なにに使うんだろう...


結局、
Gmailは問題ないが、AOL、Yahooで接続状態が長時間残ったままで新しい接続が待たされてしまい、順次接続が切断されるまでフォルダ移動が出来なくなってしまう。
mail.server.serverXX.max_cached_connections=1 にしても接続状態が残ったままなので意味が無い。
mail.server.serverXX.max_cached_connections と
mail.imap.max_cached_connections の値をいくら大きくしても最大で50を超えないので、50以上の接続となるアカウント数での利用では同じことになる。

解決策として、
接続数を50以上に増やす方法か、
AOL、Yahooで接続状態が長時間残ったままにならない方法を知りたい。

ということで
Thunderbirdのimapの動作に詳しい方からの応援を待ちましょう。
どなたかお願いします。

_________________
Administratorより投稿される皆さんへお願い:
・質問には、あなたの使用している製品名だけでなく、そのバージョンおよびOSの種類を明示してください。
フォーラムの利用に関するご案内をご一読下さい。 トピック投稿用テンプレートもご利用下さい。
・また、問題が解決した場合や入手したい情報が得られた場合は、解決した旨の返信をお願いします。


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年1月04日(火) 19:13 
kiyo4_k さんが書きました:
変更可能なパラメータで言うと
network.http.keep-alive.timeout
mail.server.serverXX.timeout
mailnews.tcptimeout
ぐらいが関係有るのか無いのか、ですかね。



えー、ちょっと間があいてしまいましたが、mailnews.tcptimeout、
network.http.keep-alive.timeoutの設定について追加で確認してみました。
mail.server.serverXX.timeoutについては、すべての値が 29だったので、
デフォルト値の情報が見つからなかったこともあり(デフォルト値を
知らないままでの変更はちょっと怖い)、特に値を変更しての確認はしていません。
全体の結論としては、特に進展もなく、細かい可能性を少しつぶしたという感じです。


確認したこと:
 下記設定にした場合に現象に改善がみられるかどうか
  mailnews.tcptimeout=10 (default 100)
結果: 変化なし

確認したこと:
 下記設定にした場合に現象に改善がみられるかどうか
  network.http.keep-alive.timeout=10 (default 115)
結果: 変化なし

確認したこと:
 下記設定にした場合に現象に改善がみられるかどうか
  network.http.keep-alive.timeout=10 (default 115)
  mailnews.tcptimeout=10 (default 100)
結果: 変化なし



念の為というか、↓についても疑問に思ったので試してみました。

確認したこと:
 下記の状況の時に新規接続が可能かどうか
  ・thunderbird全体での総接続数が 50以下
  ・アカウントの最大同時接続数に達する
  ・アカウントのサーバへの接続がすべて CLOSE_WAITになる
  ※Yahooで確認。AOLも確認しようとしましたが、20分以上たっても
   CLOSE_WAITに遷移しなかったので諦めました。

結果: CLOSE_WAITの状態になっても、新規接続は可能。

疑問/推測:
・Yahooの imapサーバとの接続は 2分から3分の間に imap サーバ側から切断されるらしい。
・timerになにも出てこないってことは、keepaliveとか有効になってない?
・この動作なら、thunderbird全体での総接続数が 50の場合でも
 できてもよさそうなんだけどなぁ...

確認内容詳細:
 3つの yahoo アカウントに下記を設定
 ・「新着メッセージがないか起動時に確認する」にチェック
   ※ mail.server.serverXX.check_new_mail=true

 すべての yahoo アカウントに下記を設定
 ・「新着メッセージがないか起動時に確認する」のチェックをはずす
   ※ 上記 3つの yahoo アカウント以外でということ
   ※ mail.server.serverXX.check_new_mail=false
 ・「新着メッセージがないかXX分ごとに確認する」にチェック、値はすべて 30分以上
   ※ mail.server.serverXX.check_time=30
 ・「サーバへの最大同時接続数」を "1"に変更
   ※ mail.server.serverXX.max_cached_connections=1
 ・「サーバがサポートしていれば IDLE コマンドを使う」のチェックをはずす
   ※ Yahooは imap idleに対応していない
   ※ この設定の about:configでの項目がわかりませんでした。

確認コマンド:
コード:
while pgrep icedove-bin 2>/dev/null
do date "+%H:%M:%S"
   LC_ALL=C netstat -top 2>/dev/null | grep imap.*mail.*imaps.*icedove-bin
   sleep 5
done | tee -a /path/to/log/netstat.log



確認コマンドの結果:
コード:
# thunderbird 起動直後
# (実 imapサーバ名は imap4.mail.vip.gq1.yahoo.com -> imap.mail.vip.sk1.yahoo.com に変動)
09:23:01
tcp        0      0 my.pc:33917 imap4.mail.vip.gq:imaps ESTABLISHED 5075/icedove-bin off (0.00/0/0)
tcp        0      0 my.pc:33918 imap4.mail.vip.gq:imaps ESTABLISHED 5075/icedove-bin off (0.00/0/0)
tcp        0      0 my.pc:33919 imap4.mail.vip.gq:imaps ESTABLISHED 5075/icedove-bin off (0.00/0/0)

# 一つ目の CLOSE_WAIT
09:25:10
tcp        0      0 my.pc:33917 imap4.mail.vip.gq:imaps ESTABLISHED 5075/icedove-bin off (0.00/0/0)
tcp        0      0 my.pc:33918 imap4.mail.vip.gq:imaps CLOSE_WAIT  5075/icedove-bin off (0.00/0/0)
tcp        0      0 my.pc:33919 imap4.mail.vip.gq:imaps ESTABLISHED 5075/icedove-bin off (0.00/0/0)

# 3アカウント全部 CLOSE_WAIT
09:26:08
tcp        0      0 my.pc:33917 imap4.mail.vip.gq:imaps CLOSE_WAIT  5075/icedove-bin off (0.00/0/0)
tcp        0      0 my.pc:33918 imap4.mail.vip.gq:imaps CLOSE_WAIT  5075/icedove-bin off (0.00/0/0)
tcp        0      0 my.pc:33919 imap4.mail.vip.gq:imaps CLOSE_WAIT  5075/icedove-bin off (0.00/0/0)

# 各アカウントのフォルダを新規に閲覧後
09:33:00
tcp        0      0 my.pc:42861 imap.mail.vip.sk1:imaps ESTABLISHED 5075/icedove-bin off (0.00/0/0)
tcp        0      0 my.pc:42863 imap.mail.vip.sk1:imaps ESTABLISHED 5075/icedove-bin off (0.00/0/0)
tcp        0      0 my.pc:42862 imap.mail.vip.sk1:imaps ESTABLISHED 5075/icedove-bin off (0.00/0/0)



とりあえず自分にやれそうなことは尽きた感じです。
えー、ネットワーク関係に詳しいわけではないので、おかしなことをしているかもしれませんが、
可能な限りの情報提供ということでお許しください。
変な点などへのつっこみもお待ちしています。


通報する
ページトップ
  
引用付きで返信する  
期間内表示:  ソート  
新しいトピックを投稿する トピックへ返信する  [ 27 件の記事 ]  ページ移動 1, 2  次へ

All times are UTC + 9 hours


オンラインデータ

このフォーラムを閲覧中のユーザー: なし & ゲスト[49人]


トピック投稿:  可
返信投稿:  可
記事編集: 不可
記事削除: 不可
ファイル添付: 不可

検索:
ページ移動:  
Powered by MozillaZine.jp® Forum Software © phpBB Group , Almsamim WYSIWYG
Japanese translation principally by ocean