关于sybase的调优

2019独角兽企业重金招聘Python工程师标准>>>

 

说明：数据库性能慢的主要原因有两个

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

 

转载于:https://my.oschina.net/ytliyang/blog/681232