浏览 1607 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2008-10-31
调优通常分三步:基础调优,运行前常规调优,运行后调优 8.1基础调优 包括操作系统调优,网络调优 操作系统的一些参数,对Coherence集群的数据传输有影响。 如:非Wins系统下Socket缓冲大小,应该至少增加到2M;Windows上的Datagram大小等,这些在官方指南中有详细的说明。 网络调优主要对交换机缓冲(Switch Buffer), Path MTU 等因素,比较常见的情况是,交换机缓存如果太小,Coherence在做Node通信时会发生延迟,Node日志一般为: 引用 Experienced a 4172 ms communication delay (probable remote GC) with Member(Id=7, Timestamp=2006-10-20 12:15:47.511, Address=192.168.0.10:8089, MachineId=13838); 320 packets rescheduled, PauseRate=0.31, Threshold=512 此时就需要增加交换机缓冲大小。
8.2运行前常规调优 指根据Coherence一般经验原则和最佳实践,在应用系统运行前分析缓存数据总量大小,计算Node个数,设置Node JVM内存等。 缓存数据总量大小(DataSize, M):根据应用规模,数据量规模,业务频度,预先估计应该纳入缓存的数据量的大小(总字节数)。对大型系统来说,可能是1G – xG。 计算节点个数:分区和Near缓存每节点只承担 M/N 的数据量,Coherence的原则是,尽量多节点,而不要将Node的内存设置过大,避免GC时间过长,一般不要超过 1G;因此,得到估计的数据总量大小M后,就可以估计需要配置的节点数,假设JVM mx为512M,则N=M/512,并据此推测需要的物理机器的数量。 JVM内存:Coherence默认为64M,每节点最大不要超过1G。并且最小和最大值设置为相同。当然可以根据项目情况,设置为 384m, 128m等。 例如: 引用 java -server -Xms1024m -Xmx1024m
GC 参数:一般应用Coherence的多为大型系统,多CPU;且缓存数据变化可能比较频繁。 引用 因此生产环境最好采用 并发的GC策略,
GC收集器个数设置为 CPU个数; 适当加大新生代的内存大小。 8.3运行后调优 系统上线后,在运行过程中,可能会出现性能不如预期的情况,或者不定期出现缓慢情况。除了对JVM 垃圾回收问题进行分析,还可以对应用进行分析,对缓存配置进行优化。 JVM 垃圾回收问题:节点GC时,会导致Node间的传输暂停,需要重传,引起集群性能下降。可可以通过Node的日志观察到,类似于: 引用 Experienced a 4172 ms communication delay (probable remote GC)
除了之前的优化交换机缓冲,还要考虑垃圾回收引起此问题的具体原因,可以通过打开垃圾回收日志进行观察,这通常可能会定位到程序代码的算法等问题。 引用 "-verbose:gc" or "-Xloggc:"
应用分析: 如果为了简便,在Coherence配置中使用 * 配置NamedCache的存储属性,那么意味着,所有NamedCache或者说一部分Cache 使用了相同的设置,如元素个数,超时时间,清除策略,前端缓存大小等。 <cache-mapping> <!—Hiberante Entity cache configuration --> <cache-name>*</cache-name> <!— 类似配置如:near-*, com.xxx.crm.customer.* --> <scheme-name>hibernate-near</scheme-name> <init-params> <init-param> <!-- 后端entry个数限制 --> <param-name>back-size-limit</param-name> <param-value>1000</param-value> </init-param> <init-param> <!-- 后端超时时间 30m --> <param-name>back-expiry</param-name> <param-value>30m</param-value> </init-param> </init-params> </cache-mapping> 但不同业务功能其数据量大小,查询频率,查询条件的多样性,数据修改的频率都是不同的,如果配置相同,则Cache机制在不同业务上体现的性能是不同的,应该区别对待,例如: 1) 数据字典修改频率极低,可以只采用local cache, 超时时间设置长一些,例如12h 。 2) 鉴权操作频率很高,因此要求高性能。鉴权数据中权限点修改频率低,但角色授权数据修改频率略高,但比一般业务也低很多,可以将 front cache设置大一些,或者只采用local访问。 3) 在Hibernate中,低频修改数据缓存配置为 nonstrict-read-write 类型;只读数据采用 read-only 型。 4) 至于业务数据,情况比较复杂。 例如:手机号码表,数据量极大,并且服务于BOSS大部分业务,并且手机号码的用户资料变更较少,因此缓存可以设置大些, 超时时间设置长些。而类似的渠道数据,数据量略小一些,HighUnits可设置稍小一些。 而对于一些修改频繁,或新增频繁的数据,超时时间(Expiry Delay) 应当设置小一些。 此类分析应该跟踪生产环境的运行情况,业务频率,修改操作频率等,进行调整优化,并跟踪调优后的结果。 9. 结束 Oracle Coherence具有一般缓存框架的极不一样的强大特性,自管理,分区缓存,线性扩展等使得它能有效提升应用,特别是大型企业级应用的性能。Coherence也是一个网格计算方案,其线性扩展也体现了“另类”的系统架构,能发挥出强大的功能。 参考资料: 1. Oracle. Coherence User-guide.htm 2. http://www.oracle.com/technology/global/cn/products/coherence/index.html 3. iniu blog http://iniu.net/iwork/2008/02/oracle-coherence.html Coherence企业级缓存(一) 特点 Coherence企业级缓存(二) QuickStart和编程 Coherence企业级缓存(三) 四种缓存类型 Coherence企业级缓存(四) 数据管理模式 Coherence企业级缓存(五)与Hibernate集成(1) Coherence企业级缓存(五)与Hibernate集成(2) Coherence企业级缓存(六) JMX 管理和监控 Coherence企业级缓存(七) 性能调优 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |