in

Darkthread

黑暗執行緒

Browse by Tags

  • 使用 DebugDiag Tools 分析 ASP.NET 站台記憶體耗盡問題

    同事報案,某測試站台不定期會發生 OutOfMemeoryException 記憶體不足錯誤,接獲通報立刻趕往事故現場,問題網站已吃掉 1.8GB 記憶體,差不多是 32 位元模式可用記憶體的上限。廢話不多說,開啟 32 位元工具管理員(C:\Windows\SysWOW64\TaskMgr.exe 參考 ) 擷取 Memory Dump 檔。 從工具箱搬出 CPU/Memory 茶包分析的小型戰術核武 - DebugDiag 2 Tools ,之前處理的都是 CPU 滿載案例,記憶體用盡分析倒是頭一遭。選用 DotNetMemoryAnalysis - Managed Memory Analysis...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 09-19-2017
  • dynamic 參數之效能損耗實測

    依據 前篇文章 :參數傳入 dynamic 會讓函式傳回值也變成 dynamic,導致無法使用 LINQ Lambda 運算式。文末提到,依據 方法多載(Method Overloading)與 dynamic 一文的研究心得,.NET 呼叫函式時若遇到參數為 dynamic 時,將改用System.Runtime.CompilerServices、System.CSharp.RuntimeBinder 命名空間物件與方法間接觸發,程序曲拆繁瑣許多。由此推測,參數傳入 dynamic 型別肯定會產生效能損耗,好奇心驅使之下,索性寫幾行程式實測親見為憑。 我設計測試程式如下,執行 100 萬次 "2017...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 08-27-2017
  • 使用非同步處理提升資料庫更新速度

    來自同事的資料庫程式效能調校案例一則。 情境為一支同步來源及目的資料表的排程,先一次取回來源及目的資料表,逐一檢查資料是否已存在目的資料表,若不存在即執行Insert,若存在則執行 Update 更新欄位。因 Insert/Update 之前需進行特定轉換,故難以改寫為 Stored Procedure。排程有執行過慢問題,處理四萬筆資料耗時近 27 分鐘。 程式示意如下: foreach (var src in srcList) { try { var target = findExistingData(src); if (target == null ) { AddTargetToDB(src...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 02-09-2017
  • SQL效能調校經驗一則

    使用者報案,某網頁效能變得奇慢無比,簡單的上線公告查詢耗時超過兩分鐘,追查後抓出問題查詢如下例: select case when convert ( varchar ,u.StartDate,108)= '00:00:00' and convert ( varchar ,u.EndDate,108)= '00:00:00' then convert (datetime, convert ( varchar ,u.EndDate,111))+1 else EndDate end as EndDate ,u.SomeNTextCol ,u.MoreCols ,u.Priority...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 05-30-2016
  • SQL筆記:再談動態WHERE條件

    前一篇文章 探討了「WHERE 1=1動態查詢條件組裝」的效能問題,並介紹如何利用C#語言特性簡單寫出沒有多餘WHERE 1=1的馬甲線SQL指令。而在前文提到的Code Review會議,還有一招不需要組裝WHERE指令的做法也被提及。 //REF: http://goo.gl/SBF1Wi by 91 /// <summary> /// 當資料物件為null時傳回DBNull.Value /// </summary> /// <param name="obj"></param> /// <param name="convEmpty">空字串是否也要傳DBNull...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 08-17-2015
  • SQL筆記:WHERE 1=1會拖累效能嗎?

    稱不上DB咖的我,反常地連寫兩篇SQL筆記,其實都是研究「動態產生SQL查詢條件」議題的副產品,這篇才算步入正題,鴨架子湯先來兩碗,烤鴨才上桌,哈!但這樣安排是對的,以下探討有一部分需要先前筆記的基礎才好聊下去。 兩週前,參加一場Code Review討論,會中大家剛好聊到「動態產生SQL查詢條件」這檔事兒。它的情境是:使用者在操作介面上有多項條件選擇,例如:日期、類別、關鍵字,每個條件使用者可選擇輸入或不輸入(不輸入代表不限定)。從程式的角度,使用者依輸入條件不同,可能形成以下幾種SQL查詢條件: 全部都不填 不需WHERE條件,查詢全部資料 填日期 WHERE Date = @date 填類別...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 08-16-2015
  • SQL筆記:Literal, Variable與Parameter

    繼續研究不同SQL寫法對執行計劃的影響。 如果大家讀過 上一篇筆記 ,就會知道以下兩則查詢將使用不同的執行計劃,前者走Clustered Index Scan,後者則是Index Seek + Key Lookup。 SELECT ProductID, OrderQty FROM Sales.SalesOrderDetail WHERE ProductID = 870 --4688筆 SELECT ProductID, OrderQty FROM Sales.SalesOrderDetail WHERE ProductID = 897 --2筆 經實測,執行計劃正如預期: 那,如果我將SQL改成這樣呢...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 08-16-2015
  • Parallel.For翻船事件剖析-使用Concurrency Visualizer

    網友Loops 留言 分享了一段程式:使用Parallel.For進行平行運算,原本測試平行運算速度勝過循序運算,卻迴圈加入一行Console.WriteLine("{0}", index)後情勢逆轉,跑得比循序迴圈還慢! 直覺推測此一現象肇因於Console為共用資源,多執行緒同時存取時涉及資源鎖定、協調同步、Context Switch等運作機制,衍生額外計算及IO。當平行處理邏輯複雜度不高,這些額外成本抵消掉平行處理的效益,甚至弊大於利,最終導致執行效率比循序處理還差。這點在 用.NET展現多核威力(1) - 從ThreadPool翻船談起 一文曾印證過。 我將Loops的程式簡化...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 12-26-2014
  • 筆記-使用VS2013解開.NET程式CPU衝高謎團

    前幾天,幫同事追查 .NET 程式 CPU 衝高問題,才發現 Visual Studio 2013 效能分析工具真是威力強大,特筆記備忘順便分享。原本想拿實務案例說明,但考量太多無關細節會失焦,所以我弄了一個簡單程式當靶機練習射擊: using System; using System.Collections.Generic; using System.Linq; using System.Security.Cryptography; using System.Text; namespace CPUSharMon { public class CPUHeater { public enum JobTypes...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 08-30-2014
  • 迴圈比對條件的陣列長度該不該用變數?

    前幾天看到關於陣列跑迴圈時,比對條件裡陣列長度改用變數提升執行效率的討論。亦即 for (int i = 0; i < array.Length; i++) ... 若改成 int c = array.Length; for (int i = 0; i < c; i++) ... 會不會變快? 支持變快的理由是比對條件會反覆執行,array.Length透過屬性取值會比直接存取變數耗時。 但有另一派 說法 : Some programmers believe that they can get a speed boost by moving the length calculation...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 02-21-2013
第1頁,共4頁 (39個項目) 1 2 3 4 下一頁 >
Powered by Community Server (Non-Commercial Edition), by Telligent Systems