最近遇到了應用程式在執行的時候,CPU 的使用率不高,但是程式像是不會動了一樣 (不是 Hang 住那樣),送過去的 Request 都沒有回應,過了幾秒鐘之後,才有回應。後來發現跟 ThreadPool Starvation 有關。
之前被教導盡量使用 ThreadPool,因為它會幫我們管理 Thread,但是卻沒有注意到使用上的一些細節。
因為 Thread 的使用相當耗費資源,而 ThreadPool 會幫我們管理 Thread 的生成,讓我們可以重複的使用 Thread,使我們的程式更有效率。但為了讓重用 Thread,ThreadPool 預設以 Processor 的數量來決定 ThreadPool 中最少的 Thread 數,例如: 我的電腦 (下圖) 有 2 Cores, 4 Logical Processors,ThreadPool 最少有四條 Thread (worker thread: 4, completion port thread: 4)。
標題還沒想好
2019年8月9日 星期五
利用 PerfView 來診斷是否有 .NET Core ThreadPool Starvation 的問題
前言
因為遇到了 ThreadPool Starvation 的問題,到找了相關的文章 (Diagnostic .NET Core ThreadPool Starvation with PerfView),但閱讀英文速度太慢,避免之後又遇到此問題,又要重新看一次,就簡單的翻譯一下;希望也能幫助到有需要的人。
以下翻譯文章。
服務無法處理爆量的請求 (在 CPU 使用率 20% 的時候,可以正常作業,但是遇到爆量的請求卻沒有使用更多的 CPU 資源)
這些症狀顯示瓶頸不在 CPU。基本上是服務的請求在等待其他資源,因而無法處理爆量的請求。最常見的例子是,請求的資源來自其他的機器。
然而有一個潛在的例子,缺乏的資源就是 Thread 本身。Service 沒有 Thread 可以執行下一個請求,所以就卡在那邊等待有可用的 Thread。此時,花了較長的時間在做資料庫查詢,但是卻不是在 CPU 活動的時間發生的,看起來像是 I/O 操作導致查詢超出原本的時間。這種問題稱為 ThreadPool Starvation。
因為遇到了 ThreadPool Starvation 的問題,到找了相關的文章 (Diagnostic .NET Core ThreadPool Starvation with PerfView),但閱讀英文速度太慢,避免之後又遇到此問題,又要重新看一次,就簡單的翻譯一下;希望也能幫助到有需要的人。
以下翻譯文章。
服務無法處理爆量的請求 (在 CPU 使用率 20% 的時候,可以正常作業,但是遇到爆量的請求卻沒有使用更多的 CPU 資源)
這些症狀顯示瓶頸不在 CPU。基本上是服務的請求在等待其他資源,因而無法處理爆量的請求。最常見的例子是,請求的資源來自其他的機器。
然而有一個潛在的例子,缺乏的資源就是 Thread 本身。Service 沒有 Thread 可以執行下一個請求,所以就卡在那邊等待有可用的 Thread。此時,花了較長的時間在做資料庫查詢,但是卻不是在 CPU 活動的時間發生的,看起來像是 I/O 操作導致查詢超出原本的時間。這種問題稱為 ThreadPool Starvation。
2016年9月27日 星期二
薩利機長:哈德遜奇蹟 SULLY 2016
中秋的補班日請了特休, 先是跟朋友去看了 NASA 太空展,結束後跟大伯臨時約了逛 Costco 逛完後,大伯說想看電影,看了看時刻表,似乎薩利機長比較能配合我們的時間。看完才知道這部片是由 IMAX 攝影機拍攝的,難怪覺得畫面特別震撼(? 應該要去看 IMAX 的才對,雖然事件的場景不多。
2016年7月24日 星期日
2016年7月17日 星期日
Javascript 我真搞不懂你啊
今天突然被指派了一項工作,要用 Javascript 寫一個 Sample code,其中有一項功能要用到時間函數;簡單的看了一下 W3C School ,挑了我適合的建構式來用:
日期函數中的月份是從 0 到 11,就因為沒有注意到這一點,所以當我把他像 C# 一樣使用的時候,我拿到物件的日期總是多加了一個月,但是我又把此物件轉成 Timesamp (Unix epoch time),所以就一直沒有注意到產生的時間錯了,下次看 W3C School 的時候,要特別注意下方黃色的說明。
日期類別注意事項:
new Date(year, month, day, hours, minutes, seconds, milliseconds)習慣寫 C# 的我,很直覺地認為建構式的參數和 C# 一樣,but 人生最厲害的就是這個 but,就因為這個建構式,花了我好幾個小時的時間才找到錯誤,看來偵錯的能力還有待加強。
日期函數中的月份是從 0 到 11,就因為沒有注意到這一點,所以當我把他像 C# 一樣使用的時候,我拿到物件的日期總是多加了一個月,但是我又把此物件轉成 Timesamp (Unix epoch time),所以就一直沒有注意到產生的時間錯了,下次看 W3C School 的時候,要特別注意下方黃色的說明。
日期類別注意事項:
- JavaScript dates are calculated in milliseconds from 01 January, 1970 00:00:00 Universal Time (UTC).
- JavaScript counts months from 0 to 11. January is 0. December is 11.
- When setting a date, without specifying the time zone, JavaScript will use the browser's time zone.
- When getting a date, without specifying the time zone, the result is converted to the browser's time zone.
另外,常用到的建構式 new Date(dateString) 其 dateString 格式為: "2015-03-25T12:00:00",字串中 T 代表的是 UTC 時間;然而此時間透過 toString() 方法得到的文字會依照瀏覽器的時區來表示時間,例如: new Date("2015-03-25T12:00:00").toString() 在我的瀏覽器 (GMT+8) 會得到以下字串:
Wed Mar 25 2015 20:00:00 GMT+0800 (台北標準時間)
訂閱:
文章 (Atom)