Python異步IO編程的進(jìn)程/線程通信實現(xiàn)
這篇文章再講3種方式，同時講4中進(jìn)程間通信的方式一、 Python 中線程間通信的實現(xiàn)方式共享變量共享變量是多個線程可以共同訪問的變量。在Python中，可以使用threading模塊中的L
早就聽說過有什么 網(wǎng)絡(luò)邊緣計算，這次還真給遇到了，有點意思，問了下 chatgpt 這是干嘛的 ?
網(wǎng)絡(luò)邊緣計算是一種計算模型，它將計算能力和數(shù)據(jù)存儲位置從傳統(tǒng)的集中式數(shù)據(jù)中心向網(wǎng)絡(luò)邊緣的用戶設(shè)備、傳感器和其他物聯(lián)網(wǎng)設(shè)備移動。這種模型的目的是在接近數(shù)據(jù)生成源頭的地方提供更快速的計算和數(shù)據(jù)處理能力，從而減少數(shù)據(jù)傳輸延遲并提高服務(wù)質(zhì)量。網(wǎng)絡(luò)邊緣計算使得在設(shè)備本地進(jìn)行數(shù)據(jù)處理和決策成為可能，同時也有助于減輕對中心數(shù)據(jù)中心的網(wǎng)絡(luò)流量和負(fù)載。
看到.NET還有這樣的應(yīng)用場景還是挺欣慰的，接下來就來分析下這個dump到底是怎么回事？
不同程序的卡死有不同的分析方式，所以要先鑒別下程序的類型以及主線程的調(diào)用棧即可，參考如下：
0:000> !eeversion5.0.721.255085.0.721.25508 @Commit: 556582d964cc21b82a88d7154e915076f6f9008eServer mode with 64 gc heapsSOS Version: 8.0.10.10501 retail build0:000> k # Child-SP RetAddr Call Site00 0000ffff`e0dddac0 0000fffd`c194c30c libpthread_2_28!pthread_cond_wait+0x238...18 (Inline Function) --------`-------- libcoreclr!RunMain::$_0::operator()::{lambda(Param *)#1}::operator()+0x14c [/__w/1/s/src/coreclr/src/vm/assembly.cpp @ 1536] 19 (Inline Function) --------`-------- libcoreclr!RunMain::$_0::operator()+0x188 [/__w/1/s/src/coreclr/src/vm/assembly.cpp @ 1538] 1a 0000ffff`e0dde600 0000fffd`c153e860 libcoreclr!RunMain+0x298 [/__w/1/s/src/coreclr/src/vm/assembly.cpp @ 1538] ...20 0000ffff`e0dded10 0000fffd`c1bf7800 libhostpolicy!corehost_main+0xc0 [/root/runtime/src/installer/corehost/cli/hostpolicy/hostpolicy.cpp @ 409] 21 (Inline Function) --------`-------- libhostfxr!execute_app+0x2c0 [/root/runtime/src/installer/corehost/cli/fxr/fx_muxer.cpp @ 146] 22 (Inline Function) --------`-------- libhostfxr!<unnamed-namespace>::read_config_and_execute+0x3b4 [/root/runtime/src/installer/corehost/cli/fxr/fx_muxer.cpp @ 520] 23 0000ffff`e0ddeeb0 0000fffd`c1bf6840 libhostfxr!fx_muxer_t::handle_exec_host_command+0x57c [/root/runtime/src/installer/corehost/cli/fxr/fx_muxer.cpp @ 1001] 24 0000ffff`e0ddf000 0000fffd`c1bf4090 libhostfxr!fx_muxer_t::execute+0x2ec25 0000ffff`e0ddf130 0000aaad`c9e1d22c libhostfxr!hostfxr_main_startupinfo+0xa0 [/root/runtime/src/installer/corehost/cli/fxr/hostfxr.cpp @ 50] 26 0000ffff`e0ddf200 0000aaad`c9e1d468 dotnet!exe_start+0x36c [/root/runtime/src/installer/corehost/corehost.cpp @ 239] 27 0000ffff`e0ddf370 0000fffd`c1c63fe0 dotnet!main+0x90 [/root/runtime/src/installer/corehost/corehost.cpp @ 302] 28 0000ffff`e0ddf3b0 0000aaad`c9e13adc libc_2_28!_libc_start_main+0xe029 0000ffff`e0ddf4e0 00000000`00000000 dotnet!start+0x34從卦中的指標(biāo)來看，這是一個 Linux 上部署的 Web網(wǎng)站，既然是網(wǎng)站的卡死，那就要關(guān)注各個線程都在做什么。
以我多年的分析經(jīng)驗，絕大多數(shù)都是由于 線程饑餓 或者說 線程池耗盡 導(dǎo)致的，首先我們看下線程池的情況。
0:000> !tThreadCount: 365UnstartedThread: 0BackgroundThread: 354PendingThread: 0DeadThread: 10Hosted Runtime: no Lock DBG ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception 0 1 31eaf 0000AAADF267C600 2020020 Preemptive 0000000000000000:0000000000000000 0000aaadf26634b0 -00001 Ukn ... 423 363 36d30 0000FFDDB4000B20 1020220 Preemptive 0000000000000000:0000000000000000 0000aaadf26634b0 -00001 Ukn (Threadpool Worker) 424 364 36d31 0000FFDDA8000B20 1020220 Preemptive 0000000000000000:0000000000000000 0000aaadf26634b0 -00001 Ukn (Threadpool Worker) 425 365 36d32 0000FFDDAC000B20 1020220 Preemptive 0000000000000000:0000000000000000 0000aaadf26634b0 -00001 Ukn (Threadpool Worker) 0:000> !tpUsing the Portable thread pool.CPU utilization: 9%Workers Total: 252Workers Running: 236Workers Idle: 13Worker Min Limit: 64Worker Max Limit: 32767Completion Total: 0Completion Free: 0Completion MaxFree: 128Completion Current Limit: 0Completion Min Limit: 64Completion Max Limit: 1000從卦中看當(dāng)前有 365 個托管線程，這個算多嗎？對于64core 來說，這個線程其實算是正常，訓(xùn)練營里的朋友都知道，server版的gc僅gc線程就有 64*2=128 個，接下來再看一個指標(biāo)就是當(dāng)前是否存在任務(wù)積壓？可以使用 !ext tpq 命令，參考輸出如下：
0:000> !ext tpqglobal work item queue________________________________local per thread work items_____________________________________從卦中看當(dāng)前沒有任務(wù)積壓，這就有點反經(jīng)驗了。
最后一招比較徹底，就是看各個線程棧都在做什么，可以使用 ~*e !clrstack 命令。
這不看不知道，一看嚇一跳，有 193 個線程在 Task.Result 上等待，這玩意太經(jīng)典了，然后從上面的調(diào)用棧 UIUpdateTimer_Elapsed 來看，貌似是一個定時器導(dǎo)致的，接下來我就好奇這代碼是怎么寫的？
分析上面的代碼之后，我發(fā)現(xiàn)它是和 Linux Shell 窗口進(jìn)行命令交互，不知道為何 Shell 沒有響應(yīng)導(dǎo)致代碼在這里卡死。
相信有很多朋友對這個反經(jīng)驗的東西很好奇為什么請求沒有積壓在線程池，其實這個考驗的是你對 PortableThreadPool 的底層了解，這里我就簡單說一下吧。
private static class GateThread{ private static void GateThreadStart() { while (true) { bool wasSignaledToWake = DelayEvent.WaitOne((int)delayHelper.GetNextDelay(tickCount)); WorkerThread.MaybeAddWorkingWorker(threadPoolInstance); } }}private bool SpinThenBlockingWait(int millisecondsTimeout, CancellationToken cancellationToken){ bool flag3 = ThreadPool.NotifyThreadBlocked();}internal static bool NotifyThreadBlocked(){ if (UsePortableThreadPool) { return PortableThreadPool.ThreadPoolInstance.NotifyThreadBlocked(); } return false;}public bool NotifyThreadBlocked(){ GateThread.Wake(this);}上面這種主動喚醒的機制是 C# 版 PortableThreadPool 做的優(yōu)化來緩解線程饑餓的，這里有一個重點就是它只能緩解，換句話說如果上游太猛了還是會有請求積壓的，但為什么這里沒有積壓呢？很顯然上游不猛唄，那如何眼見為實呢？這就需要看 timer 的周期數(shù)即可，到當(dāng)前的線程棧上給扒出來。
0:417> !DumpObj /d 0000ffee380757f8Name: System.Timers.TimerMethodTable: 0000fffd4ab24030EEClass: 0000fffd4ad6e140Size: 88(0x58) bytesFile: /home/user/env/dotnet/shared/Microsoft.NETCore.App/5.0.7/System.ComponentModel.TypeConverter.dllFields: MT Field Offset Type VT Attr Value Name0000fffd4c947498 400001c 8 ...ponentModel.ISite 0 instance 0000000000000000 _site0000000000000000 400001d 10 ....EventHandlerList 0 instance 0000000000000000 _events0000fffd479195d8 400001b 98 System.Object 0 static 0000000000000000 s_eventDisposed0000fffd47926f60 400000e 40 System.Double 1 instance 3000.000000 _interval0000fffd4791fb10 400000f 48 System.Boolean 1 instance 1 _enabled0000fffd4791fb10 4000010 49 System.Boolean 1 instance 0 _initializing0000fffd4791fb10 4000011 4a System.Boolean 1 instance 0 _delayedEnable0000fffd4ab241d8 4000012 18 ...apsedEventHandler 0 instance 0000ffee3807aae8 _onIntervalElapsed0000fffd4791fb10 4000013 4b System.Boolean 1 instance 1 _autoReset0000fffd4c944ea0 4000014 20 ...SynchronizeInvoke 0 instance 0000000000000000 _synchronizingObject0000fffd4791fb10 4000015 4c System.Boolean 1 instance 0 _disposed0000fffd49963e28 4000016 28 ...m.Threading.Timer 0 instance 0000ffee38098dc8 _timer0000fffd48b90a30 4000017 30 ...ing.TimerCallback 0 instance 0000ffee3807aaa8 _callback0000fffd479195d8 4000018 38 System.Object 0 instance 0000ffee38098db0 _cookie從卦中看當(dāng)前是 3s 為一個周期，這就能解釋為什么線程池沒有積壓的底層原因了。
這個卡死事故還是蠻好解決的，如果有一些經(jīng)驗直接用dotnet-counter也是能搞定的，重點在于這是一個 Linux的dump，同時又是 .NET上的一個很好玩的場景，故此分享出來。
本文鏈接：http://www.www897cc.com/showinfo-26-97895-0.html記一次 .NET某網(wǎng)絡(luò)邊緣計算系統(tǒng) 卡死分析
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 都用10年了，gRPC有什么不好的？
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號