一個 asp.net core 站點，之前運行在Linux 服務器上，運行一段時間后有時站點會掛掉，在日志中記錄很多“EMFILE too many open files”的錯誤：
Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvException: Error -24 EMFILE too many open files
后來將這個 asp.net 站點部署到 Windows 服務器的 IIS 上。運行一段時間后，發現其中一臺服務器出現503錯誤：
HTTP Error 503.2 - Service Unavailable The serverRuntime@appConcurrentRequestLimit setting is being exceeded.
登上服務器一看，該站點的進程占用的內存竟然有1.2G，而同一負載均衡中另外一臺正常的服務器內存占用只有40多M。然后看了一下進程中的線程數，驚呆了——竟然有8000多個線程！而另外一臺正常的服務器只有20多個線程。
將這臺服務器從負載均衡上摘下來之后，出現了更加讓人驚呆的現象——在沒有請求的情況下，這個 asp.net core 站點進程的內存占用與線程數一直在增長。就像在代碼中寫了一個死循環，在循環中不停地創建線程。
再后來內存增長到1.8G左右，線程數增長到1.3萬左右，而且還在持續增長。
不僅內存與線程數在增長，而且CPU也一直在波動，這可是在沒有任何請求的情況下，誰在偷偷地干活？
強制結束進程后恢復正常，但運行一段時間（通常是1天時間）后又會出現同樣的問題。非常奇怪！
從目前分析的情況看，罪魁禍首可能是 EnyimMemcachedCore （支持.net core的memcached客戶端，是我們從 EnyimMemcached 移植過來的），EnyimMemcachedCore 用到了 Socket 池，問題可能出在 Socket 池部分，源代碼在 github 上（EnyimMemcachedCore源代碼）。
windbg分析進程dump文件顯示的線程情況：
0:000> .load C:\Program Files\dotnet\shared\Microsoft.NETCore.App\1.0.1\sos.dll 0:000> !threads ThreadCount: 8014 UnstartedThread: 0 BackgroundThread: 8013 PendingThread: 0 DeadThread: 0 Hosted Runtime: no
發現大量線程中存在 coreclr!Thread::DoAppropriateWaitWorker 這個操作：
!uniqstack # Child-SP RetAddr Call Site 00 00000056`ed5ad118 00007ffa`080e13ed ntdll!NtWaitForMultipleObjects+0xa 01 00000056`ed5ad120 00007ff9`f1dc885e KERNELBASE!WaitForMultipleObjectsEx+0xed 02 00000056`ed5ad400 00007ff9`f1dc8a0d coreclr!Thread::DoAppropriateWaitWorker+0xfe 03 00000056`ed5ad4b0 00007ff9`f1dca52f coreclr!Thread::DoAppropriateWait+0x7d 04 00000056`ed5ad530 00007ff9`f1e3b726 coreclr!CLREventBase::WaitEx+0x7f 05 00000056`ed5ad580 00007ff9`f1e3b636 coreclr!AwareLock::EnterEpilogHelper+0xca 06 00000056`ed5ad640 00007ff9`f1f92b18 coreclr!AwareLock::EnterEpilog+0x62 07 00000056`ed5ad6a0 00007ff9`f1f92131 coreclr!AwareLock::Contention+0x258 08 00000056`ed5ad760 00007ff9`92388e2b coreclr!JITutil_MonContention+0xb1
該問題還在進一步排查中。。。
[12月3日13:00更新]
今天排查后懷疑是 EnyimMemcached 中下面的代碼引起的：
private void ConnectWithTimeout(Socket socket, EndPoint endpoint, int timeout) { var completed = new AutoResetEvent(false); var args = new SocketAsyncEventArgs(); args.RemoteEndPoint = endpoint; args.Completed += OnConnectCompleted; args.UserToken = completed; socket.ConnectAsync(args); if (!completed.WaitOne(timeout) || !socket.Connected) { using (socket) { throw new TimeoutException("Could not connect to " + endpoint); } } } private void OnConnectCompleted(object sender, SocketAsyncEventArgs args) { EventWaitHandle handle = (EventWaitHandle)args.UserToken; handle.Set(); }
已修改代碼以定位是不是上面的代碼引起的，要等待下次deadlock的發生。
[12月4日8:50更新]
終于可以重現這個問題，在有負載的情況下強制結束進程，詳見錄屏。
[12月4日12:20更新]
終于定位到了引起問題的代碼：
Task<IPAddress[]> task = System.Net.Dns.GetHostAddressesAsync(host); task.Wait(5000); var addresses = task.Result;
這是上次解決 EnyimMemcached 死鎖問題 時埋下的坑，死鎖發生在有并發請求時進行主機名的解析，在強制結束進程時重現是因為dns解析緩存失效。
改為下面的代碼可解決死鎖問題：
Task<IPAddress[]> task = System.Net.Dns.GetHostAddressesAsync(host); if (task.Wait(5000)) { var addresses = task.Result; }
雖然死鎖問題解決了，但在并發請求下task.Wait(5000)返回false，無法成功解析主機名。
問題的根源是在構造函數中用（且只能用）同步方式調用System.Net.Dns.GetHostAddressesAsync()異步方法。
最終解決方法見：嘗試解決.NET Core Framework中Dns.GetHostAddressesAsync()引起的線程死鎖
文章列表
留言列表
