关于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要打开相应工做进程数