極品狂醫 第92章解決

        性能調優是個永恆的話題。

    從我多年的工作經驗來看，沒有問題的性能幾乎是不存在的！不過，有問題並不一定需要調優：可能是沒必要，比如用了很好的機器也就遮蓋過去了；客戶認可也就不需要調了（曾經碰到一個程序運行40分鐘，只是一個人使用，她也就忍受了），還有很多方面的原因，在這就不一一解釋了。

    通常需要解決的性能問題是沒有辦法了，比如cpu100了，業務無法正常操作了，一般都是到這個時候才想起需要對性能進行優化了。

    今年有幸參加了某銀行電子銀行系統的優化，前後耗費幾個月的時間，最好總算有所成，基本解決了性能問題。

    這個系統的性能出現的問題可以是說非常嚴重，也非常奇怪，在下午，還沒有到最高峰的時候，cpu會從20直接衝到100，也就幾秒鐘的時間。

    但業務量並沒有明顯的提高，而實際上，cpu100的時候處理能力是略微下降的。

    按照一般的做法，cpu達到100忙，我們應該增加cpu，但如果那樣操作，會有適得其反的效果，這個待稍後解釋。

    由於嚴重影響了電子銀行系統的正常運行，所以我和的人都不能走了，天天在現場分析。

    開始的時候並不是很順利，通過停止業務的方法，似乎有效果，但似乎有沒有效果。

    當時cpu一到100，就停業務，要不把個人停了，要不把企業停了，有時候好像cpu就好了，但實際上都沒有效果。

    確切來說是找不到解決的方法。

    經過幾天的分析，認為有些表非常繁忙，sybase香港建議把忙的表做des綁定。

    第二天我們執行了這個操作，有一定的效果，但沒有解決根本問題。

    我們監控著，看到資料庫的spinlock競爭一直在增加，終於到了90的時候，cpu又完全100了！！！我在前一天找到了一種方法，文檔上說，如果碰到cpu異常高，又沒有確切原因的話，可以使用這個方法（好像挺玄，嘿嘿）。

    當時，我覺得很像我們碰到的現象，就把這個東西給sybase香港人說，他看了，認為不是相關的（所以說，有時候專家的話也不能信）。

    在沒有辦法的時候，我就做了這個操作（是挺大膽的，畢竟是生產系統，如果有負面問題，那就麻煩了！）。

    結果非常非常的好，cpu馬上下來了，且比之前的高峰還有低一些。

    當時的感覺真的很好，大家終於可以回家了，哈哈！後來sybase解釋說，這個操作改變了內存的替換策略，從而減少了spinlock的競爭，cpu也就不忙了。

    ase15在p6上的spinlock競爭確實非常厲害，這個問題在原先ase12.5+p5上就沒有。

    

    解決這個問題還真不是靠內存分區。

    因為通過sysmon顯示，是object的spinlock的競爭很高，最高的時候超過90。

    不是cache的，雖然這個問題解決之後也碰到了cache的spinlock高。

    ase15增加了很多查詢策略，因此其找到一個好的查詢計劃的時間大大增加。

    如果針對的sql語句本身執行時間很長，還不是問題。

    但如果是很短的sql語句，這個時間占的比重就很高了。

    我碰到的一個案例，從12.5升級到15，一個程序（由很多執行很短的sql語句組成）運行的時間提高了2~3倍，可以認為多出來的時間就是編譯的時間，大約是每個sql語句在10ms這個量級。

    因為這個原因，ase引入了statementcache，也就是對於重複執行的sql語句，不需要再編譯，找到以前已經編譯好的計劃就可以。

    這個措施對於此類sql語句還是非常有效的。

    上面這個案列打開以後，其執行時間就跟12.5上差不多，稍微增加了一些。

    當然，這個措施也有它的問題，如果由於變量不同，導致sql語句應該使用不同的查詢計劃時，就會帶來一定的問題。

    再來說電子銀行這個案例，由於之前的經驗，所以我們也打開了這個參數，並且設置該內存為1g。

    出現這個問題後，我們也試著關閉了statementcache，但cpu有明顯的升高，比原先要高一倍左右。

    這個結果用戶不能接受，所以又調整回去了。

    sysmon一直顯示objectsspinlock競爭非常激烈，而在文檔中的解決辦法就是des綁定。

    這也是為什麼我們做des綁定的原因。

    我們擔心沒有綁定出問題的表，因此，做了儘可能多的綁定。

    操作最多的前100個表都做了綁定。

    說起來這個操作還是起了一定的作用。

    至少是延緩了問題的發生。

    原先問題在2點到2點半左右就會出現，綁定後問題在3點多出現的。

    插一句話，sybase香港那個人的水平還是挺高的，經驗也很豐富，他是做pse，從產品方面給出了很多建議，也給我們一些腳本，幫助了問題的定位。

    我跟sybase，還有客戶的人，都有10年以上的sybase經驗，還是沒那麼容易忽悠的，呵呵！包括，後來的sybase美國的專家，也是很有水平的。

    雖然原來想派的一個沒到，好像叫peter，聽說那個人去年用戶大會的時候過來了，可惜那天我有事走了。

    言歸正傳，說起問題的解決辦法，不能不提到一個人：robverschoor，熟悉sybase的人很多都知道他吧。

    我也是在找不到辦法的情況下，到網上查找解決問題的方法。

    然後就找到了這位老兄的一篇文章，他提到了如果碰到cpu有不明原因的繁忙時，可以使用一個757的traceflag，同時清除一下內存。

    第二天，在sybase香港建議的方法無效後，我就大膽使用了這個方法。

    執行完畢後，效果是立竿見影，cpu馬上落下來了，而且比之前正常的時候還有低！後來sybase做了解釋，這個traceflag改變了內存的替換策略，從而降低了cpu的spinlock。

    而且我們發現，僅僅使用這個traceflag，object的spinlock還會慢慢上升，需要定期清空才能降下來。

    後來發現，statementcache不能設置太大，原來的1g改成了100m，就不需要定期清空內存了！這個案例給我的兩點是，一是cpu忙不一定要加更多的cpu；二是內存並不是越大越好！寫了這麼多，希望有人能從中得到些什麼。

    昨天真是沒啥興趣再寫，還是一個什麼版主，說我扯，沒什麼有價值的東西。

    難道提到ase15+p6的spinlock競爭沒價值？我就是先寫點兒，看看有沒人需要這些東西，如果什麼都不懂，那我還寫出來幹嘛，給誰看，那不是瞎耽誤功夫嗎！在這兒有什麼好炫耀的，如果是那樣，還不如有空歇會兒！