關於sybase的調優

 

說明：數據庫性能慢的主要緣由有兩個

       1）數據庫服務配置不合理

       2）應用程序不合理

       遇到數據庫性能降低時一般先檢查數據庫服務配置方面有沒有能夠改善的，修改以後再觀察一段時間，若是性能沒有改善的話就要分析應用程序上有沒有能夠調整的地方：索引是否合理，sql語句是否優化等。

本篇主要分析數據庫服務的配置：

問題分析：

小型機硬件：rp2470雙機、CPU700M*2、內存512M*6

如下是現場發過來的主要配置狀況：

lock scheme                 datapages  //datapages鎖模式是性能最差的鎖，通常不用

number of locks                300000  //一般不須要配置太多的鎖10萬就夠了

max memory                     500000  //物理內存3G，配給sybase的爲1G明顯不合理                                  （內存*1024*1024*0.5*60%）

number of open indexes           4000  //一般2000         

number of open objects           4000  //一般2000

number of user connections        300  //

number of worker processes          0  //多cpu要打開相應工做進程數

procedure cache size           154800  //存儲過程緩存不要超過100M

total data cache size          453699  //明顯該值過小

allocate max shared memory          0  //打開sybase佔用內存的開關

max online engines                  2          

number of engines at startup        2           

 

問題處理：

建議先調整如下配置

sp_configure "max memory",1150000              //sybase佔用2.3G內存

sp_configure "allocate max shared memory",1

sp_configure "user log cache size",4096        //用戶日誌緩存用來緩存客戶段信息 

sp_configure "procedure cache size",50000      //100M存儲過程緩存

sp_configure "number of worker processes",2

 

備份sybase主目錄下的***.cfg

sp_cacheconfig "default data cache","1G"       //配置缺省數據緩存1G

sp_cacheconfig "default data cache", "cache_partition = 2"

reboot sybase服務

備份sybase主目錄下的***.cfg

sp_cacheconfig "tempdb_cache","400M"     //因爲內存較充裕，一般會分配一部份內存給tempdb，提升查詢的速度

sp_bindcache "tempdb_cache","tempdb"     //綁定400M的內存給tempdb

reboot sybase服務

上述操做如沒法啓動sybase服務則能夠將備份的***.cfg替換當前的配置文件，從新boot sybase服務

總結：

sybase 11.9.2 & 12.0 & 早期版本的配置一般爲如下幾項：

total memory                   //定義sybase 服務可以使用的物理內存

number of lock                 //定義鎖的數目

number of open database        //打開的數據庫個數，缺省是12個，數據庫數目超過12個時要調整該值

number of devices              //數據庫的設備數，缺省是10，一般是不夠的，須要調整

number of user connections     //用戶鏈接數，根據須要設置，一般一個用戶數消耗100K的內存

這個版本的數據庫緩存、日誌緩存、過程緩存是不用手工配置的

 

sybase 12.5版本的配置一般爲如下幾項：

lock scheme                  //鎖模式，sybase推薦使用缺省（allpages），可是一些併發操做多的表（temp_telebill）要使用行鎖（datarows），減小被鎖現象

number of locks              //一般不須要配置太多的鎖10萬就夠了

max memory                   //sybase服務可以使用的物理內存，一般配置成物理內存的70％～80％，上例內存是3G，配給sybase的爲1G明顯不合理

allocate max shared memory   //打開sybase佔用內存的開關

number of open indexes       //一般2000，該值配置太低時會在日誌中報該值不夠，最終致使性能緩慢        

number of open objects       //一般2000，該值配置太低時會在日誌中報該值不夠，最終致使性能緩慢

number of user connections   //用戶鏈接數，根據實際需求來配置，盲目多配會浪費內存

procedure cache size         //存儲過程緩存不要超過100M，用來緩存過程的編譯代碼。

number of open database      //打開的數據庫個數，缺省是12個，數據庫數目超過12個時要調整該值

number of devices            //數據庫的設備數，缺省是10，一般是不夠的，須要調整

user log cache size          //日誌緩存用來保留客戶端鏈接信息的，每一個鏈接都會生成一個user log cache size大小的cache，該值缺省爲2K，主機內存充裕時能夠配成4K。

 

在12.5及之後的版本中都要手工的配置default data cache，缺省爲8M，幾乎全部的用戶操做都是在這個緩存中進行的，若是不優化的話嚴重影響數據庫性能。

優化的方法是把儘量多的內存配置給default data cache ，即：'max memory'-'全部其餘內存消耗（用戶數，鎖數等）'-‘少量預留內存’＝default data cache。

sp_cacheconfig "default data cache","1G"       //配置缺省數據緩存1G

sp_cacheconfig "default data cache", "cache_partition = 2"

 

關於cpu的配置

max online engines            //sybase 使用的cpu的個數       

number of engines at startup  //激活cpu的個數 

number of worker processes   //多cpu要打開相應工做進程數