性能是衡量软件系统的一个重要部分,可能引起性能低下的原因很多,如CPU/内存/网络资源不足,硬盘读写速度慢,数据库配置不合理,数据库对象规划或存储方式不合理,模块设计对性能考虑不足等。 1 数据库配置 1.1 SGA配置 Oracle服务器从10g开始,提供了自动共享内存管理,可以免去很多在9i上共享内存调整的麻烦。 如果你使用的是10g或以上版本,建议设置好SGA最大大小后,采用“自动共享内存管理”服务器会自动为你根据应用的情况分配各项参数的数值。 1.2. PGA配置 PGA主要用于缓存进程数据和一些控制信息,无论有多少个进程访问Oracle服务器,SGA是提供共享的内存区域,而PGA则为每个进程分别提供内存区域。因此,当访问Oracle的进程较多的情况下,PGA的内存设置也是需要注意的问题。此外,PGA空间大小对于提高缓存命中率有较大帮助。在设置其大小时,可以根据Oracle服务器对缓存命中率统计的数值进行调整,设置的大小最好能使命中率保持在95%以上。 1.3. 初始化参数设置 以下列出最为常用的数据库服务器初始化参数及其设置,注意,在设置时应使其应用在当前有效的启动文件中(spfile 或pfile),如果只是修改了当前内存中的参数,那么下次启动又会使用到修改前的那些参数取值。 a)log_checkpoint_timeout:两个检查点之间最大的时间间隔,默认1800秒。对于并发访问用户较多情况下,因为事务处理较为频繁,很容易产生数据文件与日志文件对磁盘资源的争用,因此可以适当修改该值(5000-30000) b) open_cursors:每次数据库会话最大能同时打开的游标个数,默认300。一般不需要调整,当应用过程中出现类似“游标超出最大数”的异常信息时,可以将其适当调高,如500-1000内。出现这种情况,可能是某些代码实现过程中,没有在合适的时机关闭使用过的游标,也可能是某些应用逻辑较为复杂,确实会出现峰值超出300的情况 c) sessions:数据库服务器允许并存的会话最大值,包括用户会话和系统会话。如果使 用单一的PLM服务器连接该库,但并发用户数很大,或者同时有多个PLM服务器连接该库,或其他应用需要连接库,那么比较容易导致session 到达最大值,最终产生的现象是:数据库服务器状态良好(CPU/内存使用正常),但使用pl/sql或其他工具直接访问数据库时无法连接,或很长时间才能连接上;一旦将PLM服务器 或其他连接数据库的工具退出或关闭,数据库很快恢复正常。如果是这样的现象,一般可以通过设置sessions的取值,将其适当地设置得大一些,但该值取决于软硬件条件,不能设置过大 4) shared_pool_reserved_size:共享池保留区大小,用户缓存预编译的sql 程序、存储过程等,一般情况下设置为共享池大小的5%-10%。在Oracle10g自动内存管理模式下,不需要手工调整 5) sort_area_size:内存排序工作区大小,对于提高排序运算效率很有帮助,如果设置太小,而排序运算很多时,则会转为使用临时表空间,利用磁盘空间排序性能会明显下降。一般情况下设置为PGA大小的5%-10% 1.4. 举例 1.4.1. 2 core CPU*2+4GB+RAID5+Windows2003 Server+Oracle9i x86+PLM Application/File Server SGA最大:1.5GB Java池:8MB 大型池:32MB 共享池:300MB 高速缓存:1.1GB PGA:1GB log_checkpoint_timeout:20000 open_cursors:500 shared_pool_reserved_size:20000000 sort_area_size:70000000 1.4.2. 4 core CPU*2+16GB+RAID10+Windows 2008 Server+Oracle10g x64 SGA最大:8GB,自动内存管理 PGA:2GB log_checkpoint_timeout:10000 open_cursors:500 sort_area_size:120000000 1.5. 注意事项 1. 尽量避免如同一数据库服务器为多个应用服务 2. 当物理内存在4G或更少的情况下,应尽量避免在服务器上运行其他应用程序或服务(如Web系统) 3. 如可能,尽量不在数据库服务上运行杀毒软件或其他防火墙软件,减少对网络/内存/磁盘资源的占用,尽量不要为数据库服务器开放共享目录作为软件服务器使用,尽可能保持其独立性和隔离性 4. 硬件配置和性能是软件系统高效运行的基本保证,如果没有了这个前提,很难通过软件本身的配置或优化进行有效的提升 2. 常见性能原因和对策 我们发现,有时服务器的CPU和内存使用不饱和,甚至利用率很低,但一些正常操作就是很慢;有时系统速度则时快时慢;还有些情况下则是随着时间推移越来越慢。出现这些现象的原因有多种,比如第一种情况一般说明瓶颈在磁盘读写上,第二种情况则与并发用户数或网络资源有关,第三种情况则可能是因为对服务器缺乏有效的日常维护。无论出现怎样的性能问题,应首先把握整体情况,并针对现象进行分析,必要时做出一些调整,再进行观察。找出原因是最重要的,利用一些性能监控工具(如Oracle自带的工具)是成功找到原因的一种有效途径。 根据目前PLM系统在企业运行的情况来看,出现性能问题一般有以下几种原因: a) 硬件配置低(如内存较小,CPU较慢,磁盘读写速度低,网络带宽窄) 对策:通过对硬件资源的了解,确认为该种情况后,通过硬件升级来提高。 b)数据库服务缺乏基本有效的参数配置 对策:通过查看Oracle服务配置参数,确认为参数未设置或需要优化后,根据硬件 情况对其进行设置,可参见上一章。 c) 服务器缺乏必要的日常维护,如虚存文件盘可用空间不足,数据文件盘碎片太多等待 对策:检查服务器各逻辑盘(尤其是Oracle数据存储所在盘)是否有足够可用空间,以及磁盘碎片情况,并根据情况进行调整和优化。磁盘碎片整理是一种简单有效的优化手段,必须将其作为数据库管理员日常工作来执行,定期整理非常必要。注意:整理前应将Oracle所有服务停止。 d) 数据库缺乏必要的日常维护,如没有定期进行表和索引的分析 对策:数据库管理了大量表和索引,在应用过程中,这些表或索引的数据也会像硬盘文件一样变得不连续,甚至于一条记录都分散在不同数据文件的不同数据块中,数据记录越离散,从中对其进行定位的效率就越低。因此,定期对表和索引进行整理是非常必要的。 方法1:系统管理员定期对数据库进行表分析和索引重建工作,或者在库中创建一个Job,调用PLM提供的存储过程包来自动执行以上工作。plm_optimize.stattable(‘数据库用户名’); plm_optimize.rebuildindexes; 方法2:将整个数据库重新导出/导入一次,是使数据变得连续最有效的方式,单从性能角度来说,比方法1更优。 e)软件模块的性能设计不足 对策:需要充分估计数据量增长趋势,并结合并发用户数情况,对数据库层设计进行改进 f) 其他(如:缺乏有效的索引,导致查询性能低) 对策:需针对具体情况进行监测和分析,给出解决方案。