如果發現你的dotnet core服務並發上不去，但cpu資源還比較充足那就要注意了!因為這很有可能是你沒有設置一個運行項導致...,下面要提到的就是GC.Server這玩意，實際上項目編譯中並沒有這一項設置，通過app.config設置也無效。那到底這是一個什么東西接下來說一下實際的應用效果和配置方式。
原因
最近一直做在做FastHttpApi方面的性能測試，在本機測試性能一直都比較良好；問題部署上服務器后效率竟然跑不過asp.net core webapi,這結果和在本地測完全是兩碼事；主要原因是12核的CPU無法跑到超過8核的資源，而asp.net core基本能跑滿！為了找到原因還把'Kestrel.Transport.Sockets'代碼看了一遍，怎看也不看不出有本質上的性能優勢，不過實測結果告訴我的確是這樣了；於是又仔細翻閱了代碼和配置文件也沒看到有什么特別的配置和線程配置信息，后來實在沒辦法了又看了一遍發布后的配置信息，結果看了一個System.GC.Server的配置信息。
關於Server GC的解釋
網上對System.GC.Server有實質性介紹的文檔並不太多，MSDN翻譯如下： 公共語言運行時 (CLR) 支持兩種類型的垃圾回收：工作站垃圾回收（適用於所有系統）和服務器垃圾回收（適用於多處理器系統）。 使用 <gcServer> 元素以控制 CLR 執行的垃圾回收類型。 使用 GCSettings.IsServerGC 屬性以確定是否啟用服務器垃圾回收。 對於單處理器計算機，默認的工作站垃圾回收應該是最快捷的選項。 對於雙處理器計算機，最快捷的選項既可以是工作站垃圾回收又可以是服務器垃圾回收。 對於兩個以上處理器的計算機，服務器垃圾回收應該是最快捷的選項。
從MSDN上並沒有太多講述Server GC把發揮的作用，最明確一點就是可以使用多處理器對GC進行快捷處理，至於這種配置在服務程序中具體能發揮多少作用呢沒有一個具體的指標性東西。然而以於asp.net mvc這些項目默認都會編譯成ServerGC模式並不需要配置，而我們自己寫的Console程序則不是，需要根據情況自行配置。
修改后的運行效果
於是把這配置信息復制到測試程序上，結果一跑整體的效果才出來，這個時候服務基本可以跑滿所有核資源；RPS從原來的最大14萬提高到24萬,在壓測1000萬請求的過程保持穩定。由於對GC了解不是很深入，初步猜想由於默認是單線程處理GC，這樣會導致所有線程都會卡在GC處理上；即使你加大線程池數量或加大並發也不會從根據上解決問題，只會讓並發處理延時加大！ 當在多核開啟GC Server的情況上GC就不會卡在一個線程上由多核的線程來完成，由於GC處理不會卡在一個線程，所以資源能夠完全發揮出來提高並發處理能力。
程序配置Server GC
項目屬性配置里是沒有Server GC這項設置，網上有資料說在app.config中進行配置，但這個配置對dotnet core程序是無效的。后來在MSDN找到資料需要手動編輯csproj 文件在PropertyGroup中添加相關內容.
<PropertyGroup> <ServerGarbageCollection>true</ServerGarbageCollection> </PropertyGroup>