【it168 伺服器
學院】效能調優:時間的有限和無限
oracle的效能分析在過去的20年裡已經走了很長的一段路。這裡首先提出「僅僅新增更多的資源」的方式，然後涉及比率分析，最後是等待事件分析的出現。但是那些方式都不完整或者足夠廣泛，所以在2023年我發表了一篇名為《oracle響應時間分析(rta)》的**。rta的文章同時提出並且詳細描述了響應時間中的兩個元素:服務時間和排隊時間。有關rta的乙個更加微妙的方面就是理解服務時間和排隊時間之間的關係，以及它們與作業系統之間是如何聯絡的。
使用者感覺到的響應時間是許多個相關系統的結果。oracle伺服器只是這些系統中的乙個。花費在每個系統上的時間都可以劃分為服務時間和排隊時間。我們只能把所有的服務時間和所有的排隊時間加起來，來判斷終端使用者的響應時間。但是在現實生活中，有時候這些努力相對於結果來說並不值得……不是說完成起來極端困難。但是肯定值得我們去做的最小的努力就是從oracle的角度獲取服務時間和排隊時間。此外，我們還可以獲得有關它如何與資料庫伺服器的cpu子系統相聯絡的細節。
讓我們看看基本的基於oracle的響應時間公式:
rt = 終端使用者響應時間 = ts + tw
ts = 服務時間 = cpu 時間= oracle 核心**執行時間
tw = 排隊時間 = orat + tiert
orat = oracle等待時間 (包括從伺服器程序到oracle客戶端程序的時間，以及oracle客戶端程序的時間)
tiert = 從oracle客戶端程序到終端使用者的時間。其中包括網路伺服器、網路時間、瀏覽器時間等。
從分析響應時間中我們可以穴道很多東西，其中一件就是服務時間有限，但是等待時間卻無限。每個cpu子系統都有乙個最大的固定的可以提供的cpu能力。如果你的機器是乙個cpu的，這個機器就可以提供每分鐘60個cpu秒的最大量。如果你的機器中有10個cpu，它就可以提供每分鐘600個cpu秒。這個環境對排隊時間來說絕對是不同的。
排隊時間是不固定的，並且只被工作負載所限制。如果工作負荷相對比較小，排隊時間就可能接近於0。但是當工作負載不斷增加，排隊時間就會達到無限——它沒有限制。
有關排隊時間無限的說法提出了兩個我們需要思考的概念。首先，如果oracle消耗了所有可用的cpu，那麼要求更多的cpu就需要增加服務時間，同時也有可能增加oracle等待時間。結果就是響應時間的增加。這是不好的，非常不好。這意味著我們的解決方案需要仔細權衡它們是如何影響cpu子系統的。(這個概念在我的新**《oracle等待介面詳解》中有詳細的解釋。)第二個概念就是我們現在有另一種方式來檢視乙個非常動態的系統。這不僅可以幫助我們理解系統，還可以讓我們幫助其他人來理解潛在的非常複雜的基於oracle的系統。
例如，考慮下面的圖。資料是從實際生活中的oracle系統上收集到的。每個小時、響應時間元件都會被收集並且總結。排隊時間從v$system_event中收集，服務時間是從v$sysstat中收集。通過檢視這幅圖，如果效能是糟糕的，所有的非oracle伺服器體系元件都表明不是瓶頸，瓶頸就應該是在oracle伺服器中了。通過以下的圖，我們可以推斷，io子系統有很嚴重的瓶頸，或者鎖定/阻塞問題。也許2200左右就是cpu的瓶頸，但是剩餘的時間肯定是io瓶頸或者鎖定/阻塞問題。
讓我們更仔細地看一下。問題都集中在可用的oracle消耗的作業系統的cpu能力百分比。仔細檢視上述的圖形。我們從cpu子系統開始。因為在乙個小時裡面大概消耗了大約1000分鐘的最大cpu時間，我們知道那肯定至少有17個cpu。最糟糕的情況就是使用的cpu資源相當於可用的cpu資源。這一點可以結合從上述圖形中的數字得到:
可用的cpu = 使用的cpu
x cpus * 60 分鐘/小時 = 1000分鐘/小時
x cpus = 1000分鐘/小時 / 60分鐘/小時
x cpus = 16.67
所以，資料庫伺服器上至少有17個cpu。如果我們從對作業系統的監控中發現，cpu的利用率在50%左右，大概是2200，我們還可以推斷出大概有34個cpu(16.67 x 2)。
現在讓我們把資訊放在一起，這樣它們就有用了。請注意在午餐時間附近，oracle每小時消耗的cpu時間達到1000分鐘。我們知道伺服器可以每小時提供1000個cpu分鐘，在午餐時間，它提供的時間少於每小時500個cpu分鐘，使用者並不滿意這樣的效能。因此，我們可以推斷出排隊時間(例如，oracle等待事件)並不是cpu相關的， 而是與i/o有關的，或者是相關鎖定/阻塞(例如排隊等待)。有力的資訊!
我們知道理解和應用oracle響應時間元件可以增加我們的效能威力。但是理解了oracle服務時間是如何與cpu的作業系統相關聯的，就是另乙個級別的了。在沒有理解oracle從作業系統中消耗的可用的cpu的百分比的時候，我們就無法了解是否有足夠的cpu可用。對cpu百分比的了解可以讓我們的效能診斷更加準確，可以得出更加有力的解決方案。理解了時間的有限和無限，不僅僅可以幫助你，還有你的同事，以及你需要影響的人們。他們越好的理解這個情況，他們就越同意你的行動建議。換句話說，它使得你的效能分析更加有力，構建了信任。這也是所有的資料庫管理員們都用得最多的。
Impala 效能調優和設計
優化思路 impala中，提供了10大類優化思路和方法 1.分割槽 2.連線查詢效能考慮 3.表和列資訊統計 4.impala效能測試 5.基準impala查詢 6.控制impala的資源使用情況 7.使用impala查詢amazon s3的檔案系統。8.hdfs快取 9.執行計畫和查詢概況 10....
sql的效能調優
週末火速趕到了客戶現場，週六開始幹活，查詢程式效能差的原因。經過分析，有一些還是我們需要注意總結的。如 com 元件的預設事務隔離級別，在大併發下面，是乙個很大的瓶頸。asp.net對於sp的呼叫，事務是否正常使用，也是乙個很大的瓶頸。但是對於pssdiag分析出來的結果，我還不知道應該怎麼用？只能...
mysql卡的調優思路 MySQL效能調優思路
1.mysql效能調優思路 如果一台伺服器出現長時間負載過高 週期性負載過大,或偶爾卡住如何來處理?是週期性的變化還是偶爾問題?是伺服器整體效能的問題,還是某單條語句的問題?具體到單條語句,這條語句是在等待上花的時間,還是查詢上花的時間?1.1.監測並觀察伺服器的狀態.觀察伺服器狀態,一般用如下2個...