記一次 .NET 某感測器採集系統 線程爆高分析

来源:https://www.cnblogs.com/huangxincheng/archive/2023/03/30/17272068.html
-Advertisement-
Play Games

一:背景 1. 講故事 前段時間有位朋友微信找到我,說他的程式使用 hsl 庫之後,採集 plc 時記憶體溢出,讓我幫忙看一下怎麼回事,哈哈,貌似是分析之旅中的第二次和 hsl 打交道,既然找到我,那就上 windbg 說話吧。 二:WinDbg 分析 1. 為什麼會記憶體溢出 簡單觀察程式的提交記憶體之 ...


一:背景

1. 講故事

前段時間有位朋友微信找到我,說他的程式使用 hsl 庫之後,採集 plc 時記憶體溢出,讓我幫忙看一下怎麼回事,哈哈,貌似是分析之旅中的第二次和 hsl 打交道,既然找到我,那就上 windbg 說話吧。

二:WinDbg 分析

1. 為什麼會記憶體溢出

簡單觀察程式的提交記憶體之後,發現記憶體的 Stack 區非常大,隨用 !t 看了下到底有多少個線程,截圖如下:

不看不知道,一看嚇一跳,這個程式居然有近 1.5w 的線程,雖然我見過大世面(3w+線程),但還是心有餘悸,隨用 ~*e !clrstack 看了下各個線程都在做什麼,經過一頓觀察,發現線程都卡在 Interactivelock.Enter 鎖上,截圖如下:

從代碼中看,理論上存在 Interactivelock.Enter()Interactivelock.Leave() 因為各種異常導致鎖的不成對進而造成鎖污染的情況,看起來是 hsl 代碼不嚴謹造成的什麼 bug,觀察了下版本也不是最新的,而且最新版的鎖這塊也修改了邏輯,就讓朋友升級下 hsl 再觀察看看,看樣子這個問題應該輕鬆搞定了,不過我保守的說了下,如果還是遇到大量的線程,可以隨時聯繫我。

2. 真的搞定的嗎

過了一天這位朋友又找到我,說把 hsl 升級到最新版本之後還是出現了大量線程,讓我再看一下,繼續用 ~*e !clrstack 觀察各個線程棧,發現還是卡在 pipeSocket.PipeLockEnter() 這裡,這就很迷了,代碼如下:


OS Thread Id: 0x1144 (21)
        Child SP               IP Call Site
...
000000A1AFF3DE90 00007ffa9cac6e05 System.Net.Sockets.SocketPal.Connect(System.Net.Sockets.SafeSocketHandle, Byte[], Int32) [/_/src/System.Net.Sockets/src/System/Net/Sockets/SocketPal.Windows.cs @ 118]
000000A1AFF3DEE0 00007ffa9cac6c52 System.Net.Sockets.Socket.DoConnect(System.Net.EndPoint, System.Net.Internals.SocketAddress) [/_/src/System.Net.Sockets/src/System/Net/Sockets/Socket.cs @ 4415]
000000A1AFF3DF30 00007ffa9cac6a63 System.Net.Sockets.Socket.Connect(System.Net.EndPoint) [/_/src/System.Net.Sockets/src/System/Net/Sockets/Socket.cs @ 810]
000000A1AFF3DF80 00007ffa9b7bc75a HslCommunication.Core.NetSupport.CreateSocketAndConnect(System.Net.IPEndPoint, Int32, System.Net.IPEndPoint)
000000A1AFF3DFF0 00007ffa9cac8768 HslCommunication.Core.Net.NetworkBase.CreateSocketAndConnect(System.Net.IPEndPoint, Int32, System.Net.IPEndPoint)
000000A1AFF3E030 00007ffa9cac84ba HslCommunication.Core.Net.NetworkDoubleBase.CreateSocketAndInitialication()
000000A1AFF3E070 00007ffa9cac83b8 HslCommunication.Core.Net.NetworkDoubleBase.ConnectServer()
000000A1AFF3E0B0 00007ffa9c697f8b HslCommunication.Core.Net.NetworkDoubleBase.GetAvailableSocket()
000000A1AFF3E0F0 00007ffa9c697545 HslCommunication.Core.Net.NetworkDoubleBase.ReadFromCoreServer(Byte[], Boolean, Boolean)
000000A1AFF3E160 00007ffa9c6a2779 HslCommunication.Profinet.Siemens.SiemensS7Net.ReadS7AddressData(HslCommunication.Core.Address.S7AddressData[])
000000A1AFF3E1A0 00007ffa9bfedef5 HslCommunication.Profinet.Siemens.SiemensS7Net.Read(System.String, UInt16)
...

0:021> !dso
OS Thread Id: 0x1144 (21)
RSP/REG          Object           Name
000000A1AFF3E058 00000280c8ca33d8 HslCommunication.Profinet.Siemens.SiemensS7Net
000000A1AFF3E0C0 00000281c9150e58 Microsoft.Win32.SafeHandles.SafeWaitHandle
...

0:021> !gcroot 00000281c9150e58 
Thread 1144:
            ->  00000280C8CA37E8 HslCommunication.Core.SimpleHybirdLock
            ->  00000280C8CA3860 System.Lazy`1[[System.Threading.AutoResetEvent, System.Private.CoreLib]]
            ->  00000281C9150E40 System.Threading.AutoResetEvent
            ->  00000281C9150E58 Microsoft.Win32.SafeHandles.SafeWaitHandle

0:021> !do 00000280C8CA37E8
Name:        HslCommunication.Core.SimpleHybirdLock
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ffa998a71d0  4000162       14       System.Boolean  1 instance                0 disposedValue
00007ffa998ab1f0  4000163       10         System.Int32  1 instance              614 m_waiters
00007ffa9bcea5e0  4000164        8 ...Private.CoreLib]]  0 instance 00000280c8ca3860 m_waiterLock
00007ffa998ac570  4000165      2e8         System.Int64  1   static              859 simpleHybirdLockCount
00007ffa998ac570  4000166      2f0         System.Int64  1   static              857 simpleHybirdLockWaitCount

從上面的 m_waiters=614 來看,當前有 614 個線程在等待,這裡要稍微吐槽一下,建議封裝 SimpleHybirdLock 的時候最好記錄下當前誰在持有這個鎖,不然找起來太難了。。。

經過一頓摸索發現是 21號 線程正在持有 SimpleHybirdLock,正在調用 GetAvailableSocket 方法出不來,截圖如下:

3. 為什麼獲取不到 Socket

既然有 600+ 線程在等待,大概率在獲取可用 Socket 上出了什麼問題,有了這個思路我們用 !dso 去找下 Socket 的 IP 地址是什麼,看看dump中有沒有什麼異常。


0:021> !dso
OS Thread Id: 0x1144 (21)
RSP/REG          Object           Name
000000A1AFF3E350 00000281c8ac61a8 System.Object[]    (System.Object[])
000000A1AFF3EA38 00000281c9c80608 System.String    172.16.3.208
....

提取到 IP 地址之後,接下來到用 !strings 到 dump 中搜一下可有這個 ip 相關的信息,果不其然,發現有大量的 IP 超時,截圖如下:

到這裡我們大概就知道了,原來是程式跑著跑著,由於網路等各方面的問題導致 IP 不可訪問,進而引發程式系統性崩盤。

4. hsl 真的很無辜嗎

這裡沒有任何針對性,只是從技術上進行一下探討,先上一下 hsl 對這塊的處理,簡化後如下:



public OperateResult<byte[]> ReadFromCoreServer(byte[] send, bool hasResponseData, bool usePackAndUnpack = true)
{
    OperateResult<byte[]> operateResult = new OperateResult<byte[]>();
    OperateResult<Socket> operateResult2 = null;
    pipeSocket.PipeLockEnter();
    try
    {
        operateResult2 = GetAvailableSocket();
        if (!operateResult2.IsSuccess)
        {
            pipeSocket.IsSocketError = true;
            pipeSocket.PipeLockLeave();
            operateResult.CopyErrorFromOther(operateResult2);
            return operateResult;
        }
        ExtraAfterReadFromCoreServer(operateResult3);
        pipeSocket.PipeLockLeave();
    }
    catch
    {
        pipeSocket.PipeLockLeave();
        throw;
    }
    if (!isPersistentConn)
    {
        operateResult2?.Content?.Close();
    }
    return operateResult;
}

internal static OperateResult<Socket> CreateSocketAndConnect(IPEndPoint endPoint, int timeOut, IPEndPoint local = null)
{
    int num = 0;
    while (true)
    {
        num++;
        Socket socket = new Socket(endPoint.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
        HslTimeOut hslTimeOut = HslTimeOut.HandleTimeOutCheck(socket, timeOut);
        try
        {
            if (local != null)
            {
                socket.Bind(local);
            }
            socket.Connect(endPoint);
            hslTimeOut.IsSuccessful = true;
            return OperateResult.CreateSuccessResult(socket);
        }
        catch (Exception ex)
        {
            socket?.Close();
            hslTimeOut.IsSuccessful = true;
            if (hslTimeOut.GetConsumeTime() < TimeSpan.FromMilliseconds(500.0) && num < 2)
            {
                Thread.Sleep(100);
                continue;
            }
            if (hslTimeOut.IsTimeout)
            {
                return new OperateResult<Socket>(string.Format(StringResources.Language.ConnectTimeout, endPoint, timeOut) + " ms");
            }
            return new OperateResult<Socket>($"Socket Connect {endPoint} Exception -> " + ex.Message);
        }
    }
}

從代碼中可以看到,hsl 通過 catch 捕獲到了異常,但並沒有強制 throw 讓用戶自己做決斷,而是吞到了 OperateResult 返回類中,用戶層因為偷懶又沒有判斷這種異常狀態導致了此問題的發生。 從邏輯看 Socket 是一個非常基礎的功能,所以我覺得強制拋出更合理一點,逼迫用戶可以更早的強制介入。

5. 為什麼會有那麼多線程

其實還留了一個問題沒有解答,那就是為什麼會產生那麼多的線程,很顯然這是一個 hsl 強吞異常導致的副作用,上層沒有判斷 OperateResult 的異常碼,以為一切都 ok,繼續它的周期性調度,被迫生成更多的線程池線程去赴死,危機重重,那具體是怎麼調度的呢?可以觀察各個線程的創建時間即可。


0:021> ~*e .printf "tid=%x\n",@$tid ; .ttime
...
Created: Thu Mar  9 09:02:05.541 2023 (UTC + 8:00)
Kernel:  0 days 0:00:00.062
User:    0 days 0:00:00.125
tid=38e8
Created: Thu Mar  9 09:02:10.540 2023 (UTC + 8:00)
Kernel:  0 days 0:00:00.015
User:    0 days 0:00:00.000
tid=2d64
Created: Thu Mar  9 09:02:15.540 2023 (UTC + 8:00)
Kernel:  0 days 0:00:00.015
User:    0 days 0:00:00.015
tid=3aa4
Created: Thu Mar  9 09:02:20.540 2023 (UTC + 8:00)
Kernel:  0 days 0:00:00.015
User:    0 days 0:00:00.000
tid=41ec
Created: Thu Mar  9 09:02:25.540 2023 (UTC + 8:00)
Kernel:  0 days 0:00:00.203
User:    0 days 0:00:00.218
...

從各個線程的創建時間來看,大概是 5s 採集一次。

三:總結

這次事故主要是由於在設備採集的過程中 IP 出了問題 導致的線程數暴漲引發的系統性崩潰,個人覺得朋友和hsl都有一定的責任,一個不檢查錯誤碼,一個強吞異常。

圖片名稱
您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 一、問題引入 單鏈表的實現【01】:Student-Management-System 只體現了項目功能實現,未對代碼部分做出說明。 故新增隨筆進行補充說明代碼部分。 重構代碼,迭代版本:Student Mangement System(Version 2.0) 二、解決過程 基於單鏈表實現就離不開 ...
  • 在java,c#類的成員修飾符包括,公有、私有、程式集可用的、受保護的。 對於python來說,只有兩個成員修飾符:公有成員,私有成員 成員修飾符是來修飾誰呢?當然是修飾成員了。那麼python類的成員包括什麼呢? python成員: 欄位,方法,屬性 每個類成員的修飾符有兩種: 公有成員:內部外部 ...
  • 前言 RocketMQ是阿裡巴巴旗下一款開源的MQ框架,經歷過雙十一考驗、Java編程語言實現,有非常好完整生態系統。RocketMQ作為一款純java、分散式、隊列模型的開源消息中間件,支持事務消息、順序消息、批量消息、定時消息、消息回溯等 本篇文章第一部分屬於一些核心概念和工作流程的講解;第二部 ...
  • 針對大量log日誌快速定位錯誤地方 動態查看日誌 tail -f catalina.ou 從頭打開日誌文件 cat catalina.ou 可以使用 >nanjiangtest.txt 輸出某個新日誌去查看 [[email protected] logs]# cat -n catalina.out |grep 7 ...
  • 近段時間忙於各種項目和對【易排平臺】的優化,沒顧得上分享APS相關的小技巧,回頭看看小公眾號的關註人數早已達1500+,在此爭取時間寫一下這段時間在項目上及平臺優化過程中遇到的一些小技巧,以感謝諸位的關註。過去數月的解決的問題中,涉及最多的是規劃模型中,實現各種時間維度的功能,目前在平臺上也稍有成果 ...
  • 呆了2個大屏行業的公司,對大屏幕有一些瞭解,所以整理下所瞭解的觸摸屏相關概念。方便自己以及進入這個行業的小伙伴們,能有個系統、快速的認知。 觸摸屏詳細的知識點,網上其實都有。整理資料過程中,我也瞭解了更多的觸摸屏知識,像聲波屏、光學屏之類的之前就沒接觸。下麵分不同的模塊,給大家介紹 交互觸摸屏類型 ...
  • C#-垃圾回收機制(GC) 什麼是GC 官網中有這麼一句話: The garbage collector is a common language runtime component that controls the allocation and release of managed memory ...
  • 在 IIS 上啟用 Websocket 在 Windows Server 2012 或更高版本上啟用對 WebSocket 協議的支持: 備註 使用 IIS Express 時無需執行這些步驟 通過“管理”菜單或“伺服器管理器”中的鏈接使用“添加角色和功能”嚮導。 選擇“基於角色或基於功能的安裝”。 ...
一周排行
    -Advertisement-
    Play Games
  • ## 引言 最近發現自己喜歡用的 Todo 軟體總是差點意思,畢竟每個人的習慣和工作流不太一樣,我就想著自己寫一個小的[Todo 項目]( https://github.com/circler3/TodoTrack ),核心的功能是自動記錄 Todo 執行過程中消耗的時間(尤其面向程式員),按照自己 ...
  • ### 前言 當我們編寫 C# 代碼時,經常需要處理大量的數據集合。在傳統的方式中,我們往往需要先將整個數據集合載入到記憶體中,然後再進行操作。但是如果數據集合非常大,這種方式就會導致記憶體占用過高,甚至可能導致程式崩潰。 C# 中的`yield return`機制可以幫助我們解決這個問題。通過使用`y ...
  • 1. ADO.NET的前世今生 ADO.NET的名稱起源於ADO(ActiveX Data Objects),是一個COM組件庫,用於在以往的Microsoft技術中訪問數據。之所以使用ADO.NET名稱,是因為Microsoft希望表明,這是在NET編程環境中優先使用的數據訪問介面。 ADO.NE ...
  • 1. 為什麼需要單元測試 在我們之前,測試某些功能是否能夠正常運行時,我們都將代碼寫到Main方法中,當我們測試第二個功能時,我們只能選擇將之前的代碼清掉,重新編寫。此時,如果你還想重新測試你之前的功能時,這時你就顯得有些難為情了,因為代碼都被你清掉了。當然你完全可以把代碼寫到一個記事本中進行記錄, ...
  • 1. 透過現象看本質 反射被譽為是 c#中的黑科技 ,在很多領域中都有反射的身影,例如,我們經常使用的ORM框架,ABP框架 等。 反射指程式可以訪問、檢測和修改它本身狀態或行為的一種能力。. 程式集包含模塊,而模塊包含類型,類型又包含成員。. 反射則提供了封裝程式集、模塊和類型的對象。. 您可以使 ...
  • # Rust Web 全棧開發之 Web Service 中的錯誤處理 ## Web Service 中的統一錯誤處理 ### Actix Web Service 自定義錯誤類型 -> 自定義錯誤轉為 HTTP Response - 資料庫 - 資料庫錯誤 - 串列化 - serde 錯誤 - I/ ...
  • 在前面的幾篇文章中,詳細地給大家介紹了Java里的集合。但在介紹集合時,我們涉及到了泛型的概念卻並沒有詳細學習,所以今天我們要花點時間給大家專門講解什麼是泛型、泛型的作用、用法、特點等內容 ...
  • ###BIO:同步阻塞 主線程發起io請求後,需要等待當前io操作完成,才能繼續執行。 ###NIO:同步非阻塞 引入selector、channel、等概念,當主線程發起io請求後,輪詢的查看系統是否準備好執行io操作,沒有準備好則主線程不會阻塞會繼續執行,準備好主線程會阻塞等待io操作完成。 # ...
  • 摘要:在讀多寫少的環境中,有沒有一種比ReadWriteLock更快的鎖呢?有,那就是JDK1.8中新增的StampedLock! 本文分享自華為雲社區《【高併發】高併發場景下一種比讀寫鎖更快的鎖》,作者: 冰 河。 什麼是StampedLock? ReadWriteLock鎖允許多個線程同時讀取共 ...
  • ## 併發與並行😣 ### 併發與並行的概念和區別 並行:同一個時間段內多個任務同時在不同的CPU核心上執行。強調同一時刻多個任務之間的”**同時執行**“。 併發:同一個時間段內多個任務都在進展。強調多個任務間的”**交替執行**“。 ![](https://img2023.cnblogs.co ...