性能調優是個永恆的話題。從我多年的工作經驗來看，沒有問題的性能幾乎是不存在的！不過，有問題並不一定需要調優：可能是沒必要，比如用了很好的機器也就遮蓋過去了；客戶認可也就不需要調了（曾經碰到一個程序運行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個表都做了綁定。說起
第92章解決
