<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    2. 

    <del id="afajh"><form id="afajh"></form></del>
    

    5. 

        1. <th id="afajh"><progress id="afajh"></progress></th>

          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>
          一文教會你數(shù)據(jù)庫性能調(diào)優(yōu)，附某大型醫(yī)院真實案例
          共
                3474字，需瀏覽
                    7分鐘
                
           ·
          2020-09-16 20:37
          
                    

                    

                    
                    
                    
          點擊上方SQL數(shù)據(jù)庫開發(fā)，關(guān)注獲取SQL視頻教程

          SQL專欄
          SQL基礎(chǔ)知識匯總
          SQL高級知識匯總

          前言
          微軟工程師的一個工程師曾經(jīng)對性能調(diào)優(yōu)有一個非常形象的比喻：剝洋蔥 。我也非常認(rèn)可，讓我們來一層一層撥開外面它神秘的面紗。

          六大因素
          下面祭出的是我們在給客戶分析數(shù)據(jù)庫性能問題最常用的圖。
          看完這個圖，你是不是對性能調(diào)優(yōu)有了個基本的概念了.通常來講我們會依照下面的順序來進行分析：
          1. 硬件能力
          2. 系統(tǒng)規(guī)模
          3. 數(shù)據(jù)庫內(nèi)部因素
          4. 軟件環(huán)境
          這4個的順序可以有所調(diào)整或者交換，但是對于系統(tǒng)的性能優(yōu)化一定要從全局出發(fā)。切勿一來就深入到某一個SQL語句的優(yōu)化，因為可能你花費大量的時間吧。
          一個SQL從20s 優(yōu)化到1s，但是整個系統(tǒng)的卡慢仍然存在。
          最后才是：
          1. 業(yè)務(wù)模型及架構(gòu)
          2. 代碼設(shè)計

          實戰(zhàn)案例
          不廢話了，開整開整，直接上干貨。
          時間：2019年10月某天?

          事件：某醫(yī)院客戶?下午4點?突然出現(xiàn)大面積的卡慢。整個系統(tǒng)出現(xiàn)嚴(yán)重問題，信息中心電話打爆，醫(yī)院工程師手足無措。
          萬幸的是我們給數(shù)據(jù)庫裝了‘?dāng)z像頭’，下面就從監(jiān)控錄像來看看發(fā)送了什么。然后加以解決

          硬件能力
          CPU
          在問題發(fā)生時間段內(nèi)CPU使用率在20%以下，正常。
          Memory
          從下面的圖像顯示，內(nèi)存使用正常。頁生命周期
          可用內(nèi)存
          IO
          IO隊列平均值很低，15.48 左右有個瞬時的高點，可留意這段時間有沒有批量的寫入。
          總的來看，硬件資源是足夠的。

          系統(tǒng)規(guī)模
          問題發(fā)生時，每秒的批請求書并不是一個上升趨勢，反而有所下降。這是因為系統(tǒng)的擁堵，等待 ，影響了系統(tǒng)的吞吐量。

          數(shù)據(jù)庫內(nèi)部因素
          等待
          慢語句
          從會話和慢語句的趨勢圖可以看到，問題發(fā)生的時間和客戶描述完全吻合，我們可以斷定本身事故的確是慢在數(shù)據(jù)庫。
          什么導(dǎo)致的慢
          檢查者個時間段運行中的語句,可以發(fā)現(xiàn)下午15.58左右，數(shù)據(jù)庫中開始出現(xiàn)越來越多的CMEMTHREAD等待。
          一直到1900頁16.08分的時候，出現(xiàn)了最高達100個并發(fā)同時出現(xiàn)CMEMTHREAD等待
          什么是CMEMTHREAD等待
          微軟官方的描述：
          在任務(wù)正在等待線程安全的內(nèi)存對象時發(fā)生。當(dāng)多個任務(wù)嘗試從同一個內(nèi)存對象分配內(nèi)存導(dǎo)致爭用時，等待時間可能會增加。
          這個描述很晦澀，感覺還是完全不知道等待類型是怎么回事，應(yīng)該怎么處理這類問題。
          實際上，從官方描述來看是內(nèi)存爭用的問題，但是實際上這個問題的關(guān)鍵在于多個任務(wù)的爭用，實際上是并發(fā)的執(zhí)行的問題。

          場景
          1. 出現(xiàn)在數(shù)據(jù)庫編譯或重編譯時，將即席執(zhí)行計劃ad hoc plans 插入到計劃緩存中的時候
          2. NUMA架構(gòu)下，內(nèi)存對象是按照節(jié)點來分區(qū)的
          內(nèi)存對象有三種類型的（Global，Per Numa Node，Per CPU）。SQL Server將允許對內(nèi)存對象進行分段，以便只有同一節(jié)點或cpu上的線程具有相同的底層CMemObj，從而減少來自其他節(jié)點或cpu的線程交互，從而提高性能和可伸縮性。減少內(nèi)存的并發(fā)爭用
          SELECT
          type,?pages_in_bytes,
          CASE
          WHEN?(0x20?=?creation_options?&?0x20)?THEN?'Global?PMO.?Cannot?be?partitioned?by?CPU/NUMA?Node.?TF?8048?not?applicable.'
          WHEN?(0x40?=?creation_options?&?0x40)?THEN?'Partitioned?by?CPU.TF?8048?not?applicable.'
          WHEN?(0x80?=?creation_options?&?0x80)?THEN?'Partitioned?by?Node.?Use?TF?8048?to?further?partition?by?CPU'
          ELSE?'UNKNOWN'
          END
          from?sys.dm_os_memory_objects
          order?by?pages_in_bytes?desc
          如果你發(fā)現(xiàn)，Partitioned by Node 的內(nèi)存開銷是排在前面的，可以使用TRACE FLAG 8048來減少CMEMTHREAD等待.
          從圖中可以看到，客戶的 Partitioned by Node 是比較靠后的，排在14位。
          1. 補丁
          這類場景是最常見的。如果在系統(tǒng)中發(fā)現(xiàn)出現(xiàn)大量的CMEMTHREAD等待，優(yōu)先考慮數(shù)據(jù)庫是不是已經(jīng)安裝最新的補丁
          https://support.microsoft.com/en-us/help/2492381
          https://support.microsoft.com/zh-cn/help/3074425/fix-cmemthread-waits-occur-when-you-execute-many-ad-hoc-queries-in-sql

          軟硬件環(huán)境
          目前數(shù)據(jù)庫的版本是 11.0.5556.0 而前面提到的補丁，安裝后的版本是：11.0.5623.0

          代碼設(shè)計
          是什么語句產(chǎn)生了等待？
          都是類似下面的語句，最高時，并發(fā)超過100.
          SELECT?
          ????*?INTO?#Tmp?from?TB?where?1=2
          特點如下：
          1. 語句簡單 開銷都小于5不會產(chǎn)生并行
          2. 都采用了select into #temptable的形式
          就像上面分析的一樣，CMEMTHREAD等待是一個并發(fā)問題，而不是一個內(nèi)存問題。在其他方案行不通的時候，我們可以通過調(diào)整此類語句的寫法，減少CMEMTHREAD等待.

          業(yè)務(wù)模型及架構(gòu)
          目前系統(tǒng)是單機運行的狀態(tài)，這其實是很少見的。存在少量OLAP 和OLTP業(yè)務(wù)混合的情況。后續(xù)我們會給客戶規(guī)劃 讀寫分離 或者負載均衡的解決方案。在

          解決方案
          安裝最新的補丁
          至少需要安裝前面發(fā)的解決等待問題的FIX。建議是直接安裝到目前為止最新的2012 SP4補丁。
          修改參數(shù)
          optimize for ad hoc workloads 從0修改為1 。針對將即席執(zhí)行計劃ad hoc plans 插入到計劃緩存中的時候 場景，減少ad hoc 查詢占用的內(nèi)存。
          增加TEMPDB數(shù)據(jù)文件的個數(shù)
          select * into #temptable 會產(chǎn)生大量的閂鎖爭用，防止在CMEMTHREAD 等待消除后，出現(xiàn)大量的pagelatch 閂鎖爭用。我經(jīng)歷過很多案例，解決了前面的一個擁堵之后，
          后面有產(chǎn)生了新的等待，導(dǎo)致性能更差了。請記住，優(yōu)化是一個長期的，循序漸進的過程。
          遷移TEMPDB數(shù)據(jù)文件的位置
          目前部分tempdb文件放在S，一般分放在D盤。建議都遷移到S盤(存儲上面)，增加tempdb的響應(yīng)速度。如果可能的話，使用SSD來最大化tempdb的性能，將會是不錯的選擇。
          優(yōu)化程序的代碼
          修改代碼通常都是放在最后面的，因為要牽涉的情況比較多。前面的手段80%的情況下，都可以解決問題。剩下的20%，我們需要，檢查程序中的邏輯，看看這些的語句都是什么業(yè)務(wù)產(chǎn)生的。什么條件會觸發(fā)這類業(yè)務(wù).對應(yīng)下面類似的語句都使用存儲過程，或者參數(shù)化后的方式，減少編譯和重編譯的次數(shù)。另外此類語句都會并發(fā)創(chuàng)建臨時表，可能通過調(diào)整tempdb的設(shè)置，加快此類語句的執(zhí)行速度，減少同一時間此類語句的并發(fā)數(shù)量。

          優(yōu)化效果
          經(jīng)過前面的幾個優(yōu)化手段，第二天開始，沒有再出現(xiàn)過一次CMEMTHREAD的等待。
          等待
          慢語句

          總結(jié)
          通過這篇文件你應(yīng)該已經(jīng)完全學(xué)會了數(shù)據(jù)庫性能調(diào)優(yōu)的思想。他告訴了我們出現(xiàn)問題時，怎么動手一步一步的排查問題，就像剝洋蔥一樣一層一層的剝開。

          參考
          https://blogs.msdn.microsoft.com/psssql/2012/12/20/how-it-works-cmemthread-and-debugging-them/

          作者：OwenZeng
          鏈接：https://www.cnblogs.com/OwenZeng/p/8276892.html

          ——End——
          后臺回復(fù)關(guān)鍵字：1024，獲取一份精心整理的技術(shù)干貨
          后臺回復(fù)關(guān)鍵字：進群，帶你進入高手如云的交流群。
          推薦閱讀
          這是一個能學(xué)到技術(shù)的公眾號，歡迎關(guān)注
          點擊「閱讀原文」了解SQL訓(xùn)練營
          
                
          瀏覽
                    43
          點贊
    
          評論
    
          收藏
    
          分享
        
          手機掃一掃分享
          分享
    
          
        舉報
    
          評論
          圖片
          表情
          推薦
        
          點贊
    
          評論
    
          收藏
    
          分享
        
          手機掃一掃分享
          分享
    
          
        舉報
    
          

          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            2. 

            <del id="afajh"><form id="afajh"></form></del>
            

            5. 

                1. <th id="afajh"><progress id="afajh"></progress></th>

                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  

蜜桃av秘 无码一区二区三
|
国产青榴社区
|
久久免费黄片视频
|
午夜成人网站在线观看
|
五月婷操
|