|
by developer-adjust 検索
リンク
タグ
NUnit
AJAX
Plone
ASP.NET MVC
ADO.NET Entity Framework
Haskell
ASP.NET
Ruby
TechEd
.NET
Apache
LINQ
Visual Studio
ライトニングトーク
ASP.NET Dynamic Data
Selenium
統合Windows認証
SQL Server
C#
スレッドプール
カテゴリ
最新のコメント
最新のトラックバック
以前の記事
2010年 02月
2010年 01月 2009年 12月 2009年 10月 2009年 09月 2009年 07月 2009年 06月 2009年 05月 2009年 04月 2009年 03月 2009年 02月 2009年 01月 2008年 12月 2008年 11月 2008年 10月 2008年 09月 2008年 08月 2008年 07月 2008年 06月 2008年 05月 2008年 04月 2008年 03月 2008年 02月 2008年 01月 2007年 12月 2007年 11月 2007年 04月 2007年 03月 2007年 02月 2007年 01月 2006年 12月 2006年 11月 2006年 10月 2006年 09月 2006年 08月 2006年 07月 |
2008年 08月 16日
ASP.NET スレッドプール枯渇の再現(2) の続き。
前回までで、自家製テスト用クライアントや、IEの同時接続数を増やすことができ、同時間帯の多数の Web 要求を送信できる環境がだいぶん整った。 ということで調子にのってガンガン要求送信を試していたら、またまたエラーが。 いろいろ試行錯誤しているうちに、netstat コマンドで TCP ソケットの状況を確認したところ、相当数の "TIME_WAIT" のままの TCP 接続が残っていることがわかった。 TIME_WAIT? なんじゃらほいと Google 検索であちこち調べ歩く内に、下記ページを発見。 Windowsにおけるソケットの最大値とTIME_WAITの時間を修正しよう http://nosa.cocolog-nifty.com/sanonosa/2006/04/windowstime_wai_00d2.html Windows の既定では TCP 接続が閉じられて TIME_WAIT になっている期間は 4 分とのことだそうだ。4分経過するまでこのポートは使えなくなるので、もしかするとこのことが原因で使用可能なポートが枯渇してしまったのかもしれない。 どの程度の値が最適値なのかわからなかったが、とりあえず、TIME_WAITの時間を30秒に変更したところ、エラーはでなくなり、安定してテストができるようになった。 ソケットの最大数を増やす方法もあったのだろうが、とりあえずテストが安定しだしたので、これでよしとしてみる。 ということで、いよいよ ASP.NET スレッドプール枯渇による Server too busy の再現になるかとおもいきや、これまたなかなか再現にはこぎ着けられなかった(つづく...)。
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||