SQL Server 2008 R2 效能調教課程筆記 #3 識別效能瓶頸 – CPU

在效能調教的過程中,利用工具找出最影響效能的癥結點,進而去改善效能問題,效能調教是沒有辦法說已經調教到最好,只能說在這個狀況下是不是能夠比之前發揮出更多硬體的效能,而當調教花費的成本比改善硬體更高的時候,就會選擇改善硬體規格。

怎麼辨識CPU效能瓶頸

  • Processor:% Processor Time 每一個CPU持續高達 75~80% 以上
    • 並非當 Processor 使用率很高的狀況下就是 CPU 瓶頸,使用率很高其實也是發揮出硬體原有的效能,只是平均高達 80% 而且長時間持續突破的情況下可以考慮由這方向查證。
  • Process: % Processor Time for sqlservr Process 數值高(除以CPU個數)
    • 當 CPU 使用率很高,而且大部分的 CPU 效能都是被 SQL SERVER 使用,如果 CPU 使用很高,但是 SQL SERVER 使用的很少,或許要檢查 Server 上面是不是有掛載其他程式使用掉了,固定的執行排程,又抑或是防毒軟體。
  • System: Processor queue length > 2
    • 執行的等待時間持續大於 2 ,幾乎可以斷定是 CPU 瓶頸,每個執行都必須等待兩個以上。
  • Wait Type 中的 CXPACKET 數值非常高
  • DMV 語法中的 runnable_tasks_count 數值持續不為0

造成CPU使用率高的原因

  • 大量並同時的批次作業造成系統無法負荷
    • 在半夜執行的批次作業可以錯開時間

image

  • 查詢的執行計畫(Execution plan)沒有效率
    • 可能是因為索引的關係原本少數資料的 Index Seek 必須要由 Index Scan 來執行
  • 過度的編譯(Compilations)及重新編譯(Recompilations)發生
    • 高比率的(SQL Recompilations/sec)/(Batch Requests/sec)指出重新編譯是導致CPU使用率高的原因,利用參數式查詢,避免每次動態語法重新編譯。
  • 不正確使用平行處理計畫(Intra-query parallelism)
    • 在多 CPU 的 Server 上,SQL Server 在預設行為下遇到需要大量 CPU 的語法執行時候,會自動執行平行計算使用所有的 CPU ,因此可能讓某一項需要長時間運算影響到整體 Server 。OPTION (MAXDOP  1) 可以設定使用單一 CPU 處理單一語法,避免因為一個怪獸級的動作消耗掉全部的效能。
  • 不正確使用伺服器端游標(Server side cursors),影響SQL Server效能

SQL Server 2008 (R2) 效能調教及工具應用專班!!

SQL Server 2008 R2 效能調教課程筆記 #2 基本工具 SQL Profiler

相對於 Performance Monitor 來說,SQL Profiler 是我比較熟悉的工具,如果有使用 ORM 工具也會用這種方式來看真正執行的 T-SQL。

image

指在資料庫階層工具>SQL Server Profiler,這邊需要有資料庫權限才有辦法開啟。

選擇相關的追蹤資料,上課的講師有建議
• Stored Procedures
• RPC:Completed(已經完成遠端程序呼叫)
• SP:stmtCompleted(已完成預存程序內的 T-SQL 陳述式)
• TSQL
• SQL:BatchCompleted(已完成 Transact-SQL 批次)
• SQL:StmtCompleted(已完成 Transact-SQL 陳述式)
• Errors and Warnings
• Audit login / logou

image

如果有選擇儲存至檔案,紀錄完畢會得到一個 trc 檔案,重新開啟 trc 檔案可以看到匯入效能資料。

image

利用這種方式可以將 SQL Provider 資料與 Performance Monitor 資料合併顯示。

image

選取某一段 CPU 很高的時間點也會顯示同時間執行的 SQL 語法,要匯入的資料必須是時間點上有重疊的部分,不然會沒有辦法匯入,如果相對應時間點沒有另一個紀錄的資料也會無法顯示。


SQL Server 2008 (R2) 效能調教及工具應用專班!!

SQL Server 2008 R2 效能調教課程筆記 #1 基本工具 Performance Monitor

上個禮拜有幸去參加了微軟講師 Ray 的課程,真的是有醍醐灌頂的感覺。平常上網爬文跟現場的教學真的還是有差距,不過代價也是差了很多就是,如果是個人自費的話應該也花不下手吧。趕快趁著上完課記憶還在的時候能記多少就記多少,不然平常程式開發也比較少上線後效能調教的經驗。

要調教效能的情況下通常是因為客戶覺得反應速度太慢,反應速度慢的情況又有很多種,有可能是因為使用人數或資料隨著成長造成的,也有可能是因為程式邏輯太過複雜,或是硬體真的發生了問題,太多太多種可能的狀況,所以還是需要一些工具來輔助。

Performance Monitor

這是 windows 內建的功能,直接開始>執行>perfmon 就可以開啟 Performance Monitor

image

也可以利用新增功能增加要監視的系統數值

image

除了即時監控的功能,也可以設定將記錄的資料儲存下來,再利用分析工具來分析效能不佳的原因

image

設定需要紀錄的項目,有些項目是比較不需要的,全部紀錄的話資料量太多也會影響分析的速度,在使用 Performance Monitor 的時候也會影響一些系統效能。但是如果要調教的話還是需要這些資料來做分析的動作。

image

影響效能這邊在紀錄的間隔時間可以來做一個設定

  • 總紀錄時間兩小時-每四秒一次
  • 總紀錄時間一天-每30秒一次
  • 總紀錄時間五天-每180秒一次

當然間隔時間愈長,為了紀錄所影響的效能愈少,但是為了取得需要的資料量,就需要比較長的紀錄時間。不過最重要的是在記錄時間內確實有發生效能問題,不然拿系統運作良好的紀錄要分析出效能低落的原因就比較困難了。

image

設定完了之後就會出現自定義的項目,在這邊的 右鍵>內容也可以進一步設定排程開始結束相關設定,如果問題發生是固定半夜兩點就可以設定早十分鐘先啟動紀錄,記錄問題發生的時候系統的狀況。

另外如果有大量的 server 需要紀錄的話,不太可能一台一台電腦設定,Performance Monitor 也有支援 command 語法設定紀錄或排程。


SQL Server 2008 (R2) 效能調教及工具應用專班!!

利用 Swipe Event 控制換頁

image
Carousel 效果是我認為在 Mobile 上面最難處理的部分,大部分的作法都是用一個長條 div 只顯示其中一部份,再用 css : Left 或是 Top 去控制顯示的部分。如果是 jQuery 早期的動畫效果 jquery.animate() 就算是 ipad2 跑起來也是超頓的,唯一的解法就是利用 –webkit-Transform 來做處理。
在 jQuery Mobile 上面預設在換頁的時候就會觸發 –webkit-Transform 來處理換頁的特效(在不支援的瀏覽器上面會直接換頁顯示),但是這邊的特效跟其他 Framework 呈現方式比較不一樣的是在觸控移動的時候 jQuery Mobile Swipe 的方式是當使用者手指移動超過一段距離之後,就觸發 Swipe 事件。其他的 framework 如果有將 touchstart ,touchmove ,touchend 分別做處理的話,就可以在手指移動的同時就做畫面移動的效果,然後在 touch end 手指離開計算距離決定要不要呈現下一頁,抑或是距離不足就停留在原本頁面。jQuery Mobile 目前看起來沒有太重視這一塊,感覺他們的主要目標還是在容易開發、廣泛支援上面。

Swipe Events

基本上 jQuery Mobile 就是讓你很容易套用,所以要取得滑動的事件只要註冊 swipe event 就可以了,jQuery Mobile 利用 javascript 的 touch event 如果長度超過一定距離就觸發 swipe event。

  • 預設在一秒之內移動水平距離超過 30px 而且垂直小於 20px ,就會觸發 swipe 事件。
  • $.event.special.swipe.horizontalDistanceThreshold = 130; 設定 horizontalDistanceThreshold 參數,將原本水平移動距離 30px 改為 130px 之後,他才會觸發 swipe 事件,這邊就是根據測試的習慣來修改,避免因為太容易換造成其實 user 並沒有想要換頁,但是事件被觸發。
  • durationThreshold Swipe 動作要在多少時間下被完成,如果超過這個時間就不觸發 Swipe 事件,預設 1000 (ms)。
  • verticalDistanceThreshold 垂直移動不能超過多少(px)才觸發 Swipe。
  • scrollSupressionThreshold 水平移動超過多少(px)就停止原本垂直滾動。

Example

一開始我先建立一個 js 物件

Site: {
PrePage: { Url: "" },
NextPage: { Url: "" }
}

全網站註冊 Swipe 事件,只註冊一次

$(document).ready(function () {
$.event.special.swipe.horizontalDistanceThreshold = 130;
$(document).bind("swipeleft", function (e) {
$.mobile.changePage(Site.NextPage.Url, { transition: 'slide' });
});
$(document).bind("swiperight", function (e) {
$.mobile.changePage(Site.PrePage.Url, { transition: 'slide', reverse: true });
});
});

在每一頁載入的時候去修改物件的值

$('div:jqmData(role="page")').live('pageinit', function () {
Pru.Site.PrePage.Url = '@(PreviousSibling.Url)';
Pru.Site.NextPage.Url = '@(NextSibling.Url)';
});

這邊我是用 mvc3 Razor 搭配 ASP.NET MVC SiteMap provider 來控制,強力推薦 ASP.NET MVC SiteMap provider 很好用喔。全網站事件我只有註冊一次,如果在每一次 pageinit (pageint 是 jQuery Mobile 事件,ajaxload 新頁面進來觸發) 重複註冊的話,就會變成一次 swipe 換了好多頁。也有考慮過利用 bind unbind 來控制,但是似乎不是很容易,目前感覺上還是用 js 物件操作會比較方便。


jQuery Mobile | jQuery Mobile

jQuery Mobile #2 切換頁面的特效處理

jQuery 只是 plugin 但是 jQuery Mobile 是 Framework ,他在一引用的時候就自動幫你擋掉所有 A.Link 的動作,就是要你照他的規矩來玩。也有內建很多效果在 A.Link 切換頁面的時候來展現。雖然說效果不比 Sencha Touch 或是其他的 Mobile js Framework ,但是 jQuery Mobile 強調的就是多支援,支援度絕對沒有別家比得上,不用再花很多時間去調整各家瀏覽器、各家 OS 還有各家 OS 上的不同瀏覽器,講到舌頭都打結就知道支援度是多麼可怕的東西。

data-transition

<a href="index.html" data-transition="pop">彈出效果</a>

jQuery Mobile 利用 data-transition 來設定不同的效果,有 slide , slideup ,slidedown ,pop ,fade ,flip 都只要設定上去就可以看到效果了。

<a href="/index.html" data-transition="reverse slide" class="上一頁">

Slide 預設是由右方滑入,如果想做左邊一頁的話就是要設定為 reverse slide 。非常貼心的一點是,當套用效果切換頁面的時候,這時候回上一頁也會使用反向的效果來顯示。

data-rel=”dialog”

<a href="/index.html" data-rel="dialog">

設定 dialog 的情況下,連結頁面會用彈出的來顯示,而且彈出不會記錄在瀏覽器的 history 裡面,上下頁就不會切到彈出這頁。

rel=”external”

<a href="/index.html" rel="external">

如果連結的位置是由 http://||https:// 開頭,jQuery Mobile 就不會幫你做任何處理,直接開啟新頁面。但是如果在內部連結可是也不想要 jQuery Mobile 做什麼事的話,就加上 rel=”external” ,假設說新頁面沒有依照 jQuery Mobile 的 Html 規範走的就必須加上,不然再 ajax loading 的時候就會因為判讀不正常出現 error。


http://jquerymobile.com/test/docs/pages/page-transitions.html

jQuery Mobile #1 開始建立一個新的 jQuery Mobile 專案

image

這幾天非常的慘烈,奉勸如果有想要進來開發 Mobile Web 的同好,一定要謹慎評估 Framework 的使用,話說最初我也是非常堅持在效果上,如果能做到像 app.ft.com 這種水準的網站,真的是作夢都會笑。不過最終繞了一大圈,我還是又回到了 jQuery 的懷抱。當然有非常多的原因,時程的壓力、擴充性跟可維護性、不過讓我最後下定決心的還是因為客戶希望時程內要能在 windows phone & IE 上正常瀏覽。

雖然百般無奈,但是開始用了 jQuery Mobile 三個小時之後,其實比我想像中的還要好一些。而且最重要的是,我開始懷抱過年可以賴在家看電視的夢想了。

基本 html 架構

<!DOCTYPE>
<
html>
<
head>
<
title></title>
</
head>
<
body>
<
div data-role="page">
<
div data-role="header">
</
div>
<
div data-role="content">
</
div>
<
div data-role="footer">
</
div>
</
div>
</
body>
</
html>

  • 如果要使用 jQuery Mobile 預設會需要這幾個 div 用 data-role 去設定,分別是 page,header,content,footer,有了這幾個 div 預設的動作才會正常,不然會一直呈現鬼打牆狀態,像是超連結點下去沒有反應之類的…。我第一件發現的事情是 jQuery Mobile 把全部 <a> 的動作都吃掉了(如果超連結是 http:// | https:// 開頭的不會,吃掉的是站內連結),預設會取代成 ajax loading 來做換頁的效果。
  • 使用預設的 ajax loading 的時候,載入的頁面也必須包含這幾個 div , jQuery Mobile 在背景做 loading 頁面的動作,然後把 <div data-role=”page”></div> 之間的資料做更新的動作。
  • jQuery Mobile 最大的優點就是他真的在跨瀏覽器上面做了很多的功夫,像是 pushState 還有 webkit transform 這些很不錯但是又有人不支援的功能,都有默默的判斷。如果說將來 Mobile OS 市場愈來愈多人加入戰局的話,考慮使用 jQuery Mobile 的應該也會大增。


jQuery Mobile | jQuery Mobile

HTML5 applicationCache javascript Events

image

利用 manifest 可以做到 application cache 在頁面載入的時候,瀏覽器就會先確定 manifest 中每個文件是不是都已經存在 application cache 裡面,上面的畫面就是 chrome 在確認的時候 console 顯示的資訊。

appCache = window.applicationCache;
appCache.addEventListener('cached', handleCacheEvent, false);
appCache.addEventListener('checking', handleCacheEvent, false);
appCache.addEventListener('downloading', handleCacheEvent, false);
appCache.addEventListener('error', handleCacheError, false);
appCache.addEventListener('noupdate', handleCacheEvent, false);
appCache.addEventListener('obsolete', handleCacheEvent, false);
appCache.addEventListener('progress', handleCacheEvent, false);
appCache.addEventListener('updateready', handleCacheEvent, false);

IE7,8 在 addEventListener 會沒有第三個參數,不過反正 IE 7,8 也不支援 application cache ….

checking

每次重新載入頁面都會觸發這個 event ,檢查 application cache 的檔案

downloading

manifest 檔案有被修改過,開始下載前觸發

progress

下載檔案的時候觸發,注意的是每下載完一個檔案就會觸發一次喔

cached

檔案全部被 cache 了,但是這個事件是第一次進入的時候 cache 完成發生的。

noupdate

manifest 檔案沒有修改過

updateready

不是第一次進入這個頁面,manifest 有修改過,而且下載已經完成,cached,noupdate,updateready 都是 application cache 沒有發生異常的狀況下最後一個事件。

obsolete

如果 manifest 檔案回傳給你 404 或 410 就會發生這個 event

Error

就是發生錯誤的時候囉,瀏覽器在一開始確認跟最後的時候都會確認 manifest 檔案。之前就發生過一個狀況是因為我不想要每次測試都修改 manifest 檔案,所以就讓 manifest 動態產生,再給他一個 # 加上 Datetime.Now.ToString,結果每次都錯誤,因為瀏覽器在第一次 checking 跟最後確認的時候取得的 manifest 檔案是不一樣的。

另外 manifest 檔案的 MIME 必須是 text/cache-manifest 而且編碼是 UTF-8,如果適用 IIS Server 就必須在 IIS 下的 MIME 額外去設定附檔名對應,預設副檔名 manifest 對應的是 application/x-ms-manifest ,目前看起來針對 application 的 manifest 似乎也沒有公認的副檔名,各家網站設定也都不一樣,反正只要回傳的 MIME 是 text/cache-manifest 就 OK 了


6.6 Offline Web applications — HTML Standard

HTML5 Rocks – A Beginner’s Guide to Using the Application Cache

Using HTML5 Offline Application Cache Events In Javascript