网站用什么系统,已备案网站域名,全国软件开发公司排名前一百,网站建设合同贴花算哪一类Sybase数据库应用系统调优的五大领域 2011/3/14/13:49来源#xff1a;慧聪it网本 文以“某大型商业银行的网上银行系统”这一很具有典型意义的企业级大型Sybase数据库应用系统为例#xff0c;涉及了数据库应用系统调优的五大领域#xff1a;压力测试、 应用端调优、服务器端… Sybase数据库应用系统调优的五大领域 2011/3/14/13:49来源慧聪it网 本 文以“某大型商业银行的网上银行系统”这一很具有典型意义的企业级大型Sybase数据库应用系统为例涉及了数据库应用系统调优的五大领域压力测试、 应用端调优、服务器端调优、系统平台层的优化、应用架构的优化详细介绍了作者在项目开发过程中曾经遇到的各种问题及其解决办法。本文通过对“企业级 Sybase数据库应用系统的性能调优的最佳实践”的探讨从而为这类性质的工作提供了具有普遍指导意义的参考。 1.项目背景与特点 该应用系统是在总结前一代网银系统的经验教训的基础上于2008年开始彻底重新设计、开发的。 技术上它从J2EE技术架构转向.NET架构大幅度提高了应用程序的开发效率、运行效率改善了最终用户的实际体验 UserExperience业务上同时推出了“个人网银”、“企业网银”、“手机银行”等使该行在非传统业务渠道上实现了跨越式发展迅速赶 上并超越了同行产品上从SybaseASE12系列产品升级到15系列产品以便充分利用其高性能、高可靠性特征。 2.系统逻辑架构 如图所示该系统共分3个层次有数个关键组件—— 接入层AccessLayer包括防火墙Firewall、网络负载均衡设备LoadBalancer等 应用及管理层ApplicationManagementLayer包括静态网页服务器 StaticPagesHTTPServers、面向不同业务的多组应用服务器GroupedApplicationServers、证书管理服 务器CALDAP、Sybase数据库服务器、各种系统管理监控工具等 后台接入主要是接入各种后台系统的网关BackendGateways如主机交易网关等。 点击此处查看全部新闻图片 3.系统的业务量 在衡量网上银行的业务交易量时通常用两类业务指标一类是账户类交易即涉及用户账户核心信息特别是账户余额的交易如“交 易明细查询”、“转账”、“缴费”等另一类是辅助交易如“常用关联账户/收款方管理”、“证书/口令管理”、“理财产品信息”、“用户定制菜单管理” 等等。 在本项目中我们用如下的系数关系描述系统的业务量如果“账户类交易量”为则“辅助交易量”为0.6SybaseASE数据库系统的总业务交易量为1.6。如果不特别指明本文主要使用“账户类交易量”“总业务交易量”的表达方式。 该项目的几个关键点列示如下 2009年7月刚刚上线时其业务交易量约为300万笔/天480万笔/天 2009年年底时其业务交易量增长到600万笔/天960万笔/天 2010年5月初达到1000万笔/天1600万笔/天 2010年10月初达到1500万笔/天2400万笔/天 未来2年内的业务压力预计是每天3000万笔4800万笔/天该目标很可能在2011年底提前达到。 4Sybase数据库应用系统调优的五大领域 1压力测试领域 从笔者观察到的行业现状看在应用系统上线前通常会有不同形式的功能测试但压力测试的普及度很低即使有压力测试也通常不能 很好地预测未来的系统表现。其造成的客观后果是大多数大型数据库应用系统一定会在实际运行过程中发生性能问题并且这种性能瓶颈通常过早地出现没有能 够充分发挥系统软硬件资源的潜能。 究其原因除了要强调压力测试对于大型系统的必要性还要改进压力测试的方法。我认为在压力测试领域应该注意个关键问题即“业务指标的确定策略”、“业务压力的模拟策略”、“性能评测指标的选取策略”。 (2)数据库应用端的调优 要进行数据库应用系统的调优最好的着力点是从数据库应用端出发找出实际运行效率低下的应用模块/。 传统的定位方法是在应用逻辑中、或在应用模块调度/总控程序中加入“测控模块/语句”衡量每个模块/语句的“入/出时间点” 从而得到其执行时长。这种方法容易理解常在系统调试阶段使用也常用于层次化应用LayeredApplication环境中的层间隔离。但其缺点 是这种方法会加重应用开发团队的负担不容易运用于已经上线的生产系统中。 对于数据库应用中的SQL模块/语句方面的性能问题我们推荐具备网络嗅探NetworkSniffing机制的工具如美国 WhiteSands公司的ProActiveDBA。它能够借助于网络监听在毫不影响应用系统的情况下计算出每个SQL语句/模块的“入/出时间 点”从而得到其执行时长找到有效率问题的部分。 但是按照其实际执行时间来排序、筛选的上述方法并不一定能找出所有可能构成系统瓶颈的SQL。还有另外一种情形需要注意——某 些SQL由于各种原因例如其涉及的数据较少、逻辑简单等其单独的执行时间并不很长、很不起眼但是其执行频度/总次数特别多其累计的内存I /OSybase称其为逻辑I/O特别多因此会消耗大量的CPU资源。这时系统通常会表现为CPU特别忙整体吞吐量下降。 对于这种情形传统的测控手段可能会失效。相应的补救手段是充分利用SybaseASE中早就存在、且在15版本中更加完善的各 种监控用系统表MonitoringTables也叫MDA表MonitoringandDiagnosticstables。 3数据库服务器端的调优 数据库服务器端的调优是数据库管理员DBA最重要的工作本文无法也无意去赘述SybaseASE服务器调优的方方面面只根据在此网上银行项目中的经历重点提示某些关键内容特别是与ASE15相关的调优技巧。 3.1StatementCache调优特别是traceflag757与CPU忙问题 自12.5.2版本起ASE增加了StatementCache机制。作为对传统存储过程StotedProcedure处 理机制的扩展它被用于存放即席查询adhocSQL的SQL文本、执行计划以便改善同类SQL的执行效率减少了SQL的再编译 recompiling时间。 其实际效果取决于应用系统的特点有些系统对此机制根本不敏感某些系统则能够得到几十个百分点甚至数倍的性能提升。 在启用该机制时一般建议同时启用enableliteralautoparam参数以便将语句主体相同、只是参数不同的相似 SQL归为同类提高StatementCache的效率。本项目的最大教训来自于StatementCache的“大小配置”与“分配策略”以及可能 由此引发的系统级性能问题——CPU使用率高企却原因不明。 3.2ProcedureCache调优 自12.5.2版本起ASE引入了StatementCache机制并且把它作为ProcedureCache的一部分。同时 缺省的ProcedureCache也不再是整个Cache的20%而是通过单独的服务器参数procedurecachesize来设定。 相较于ASE12.5ASE15需要更多的ProcedureCache。因为它采用了更大的内存分配单元其重新设计的查询处 理引擎需要更多的内存来评估新添的数据访问算法allrows_dss和allrows_mix的优化目标也比allrows_oltp消耗更多 ProcedureCache更不用说索引统计直方图histograms、排序用空间sortbuffers等。 因此ASE15的ProcedureCache虽然不必达到早期版本中的整个Cache的20%但也通常是ASE12.5的ProcedureCache的倍。 (4)系统平台层的调优 近些年来硬件业的飞速发展让我们这些数据库管理员DBA越来越少地去操心内存大小、网络带宽、磁盘吞吐能力等等系统平台层要素尤其是在数据库服务器专用的硬件环境中。 正是长时间的放松让我们在本项目的调优中走了弯路 (4.1)SAN存储的调优CPUSpikes问题 在本项目的某个时期发生了数次“间歇性的CPU利用率冲高CPUspikes”。这与前述的因为 StatementCache分配策略引发的CPU利用率高企现象有相同之处都会使CPU利用率升高、影响整个系统的吞吐量。二者也有差异性前者持续 时间长伴随着很高的“ObjectManagerSpinlockContention”后者持续时间 短“ObjectManagerSpinlockContention”也没有那么高。 在逐一排除了前述的SQL问题、统计值问题、索引问题、数据类型匹配问题、StatementCache等等因素之后我们才不得不扩大排查范围——同时对数据库服务器与磁盘系统采样缩短采样周期提高采样次数比较正常时段、异常时段系统的关键指标。 我们终于发现每一次“间歇性的CPU利用率冲高CPUspikes”都对应着磁盘系统 “AverageServiceTimes”的增加。即大部分磁盘明显变慢约33的设备慢2倍以上11的设备慢10倍以上对应地数据库的 “LogSemaphoreContention”跳升了20多倍“PLCLatchContention”跳升了13倍 由此说明虽然SANStorageAreaNetwork与LVM带来了很多益处但也应当仔细规划。最常见的是那种 “StripeEverythingEverywhere”的存储设计模式即把所有数据库对象都打散在逻辑卷LV上、LV打散 stripping在由数个PV组成的diskgroup上、一个SAN存储及其I/O通道为多个机器上的多个应用共享。这种模式的最大不足是多个 机器上的多个应用系统之间通过共享的SAN相互影响难以进行性能调优难以实现灾难恢复DisasterRecovery。对于性能要求比较高的超 大型数据库应用系统我们还是建议配置专用的硬件无论是SAN、网络等等。 (4.2)NAS存储的调优 近年来NASNetwork-AttachedStorage存储被越来越广泛地使用因为与SAN相比它成本更低、文件共享更容易、对客户端要求更少。 本人曾经有一个难以忘怀的经历。某个工作日的下午点客户的Sybase数据库系统发生故障6G的事务日志即将被用完且无法清除所有数据修改交易即将被挂起 事实说明NAS不同于SAN、DASDirectAttachedStorage它毕竟不是主机的直连存储设备且通常没 有SAN那样的专用高速网络支撑受网络连通性、稳定性、压力大小、网络性能的影响很大。在高可用、高性能的大型数据库应用系统中我们不建议NAS空间 参与数据库的直接操作无论是DUMP/LOAD、BCPIN/OUT更不用说用作数据库设备。当然可以变通地进行阶段处理如先将数据库DUMP 到本地或SAN上再转存到NAS上。 5架构级调优 5.1数据库/应用级的拆分理论上的多库结构与现实中的单库结构 众所周知Sybase不同于Oracle从它诞生那天起就可以在单个服务器中支持多个数据库。按照一个应用对应一个用户数据 库UserDatabase的惯例Sybase服务器可以在理论上支撑多个数据库应用。伴随着硬件技术的飞速发展、集中式数据中心的再度流行越来 越多的用户倾向于在一个ASE服务器上运行多个数据库应用因为这样易于管理。 但事情总是存在着两面性对于可靠性、性能要求都很高的大型数据库应用系统单个服务器毕竟存在着可靠性方面的互相干扰和性能上的瓶颈无论是CPU、内存、还是TEMPDB不利于安排系统维护窗口、进一步提升性能。 事实上对于现有各种面向OLTP的关系型数据库系统的多机系统其可靠性方面的收益大于性能方面的收益。我们建议为了达到最好 的性能扩展性数据库应用系统应该首先在应用架构层面考虑多服务器/多数据库架构即在必要时单个应用系统应该能够很容易地拆分到多个服务器上这是应 用架构级的真正可扩展性 5.2数据表级的拆分SybaseText/Image字段与LatchSleep问题 本项目的另外一大收获是对ASELatchSleep现象的探究及其由此找到的提高SybaseText/Image字段修改效率的方法。这在以往的工作中并不多见却是长久的疑惑现总结如下。 Latch也叫Spinlock是ASE针对“内部数据结构如DataCache、 Object/IndexMetadataCache.”的一种并发访问管理机制以保持页面的物理一致性只存在于SMP环境下。它是轻量级的、非事 务性的lightweightnontransactional。 结语 本文的意义在于该项目的客观实践再次证明了借助于Sybase/UNIX平台可以构造全国性的超大型数据库应用系统 大型数据库应用系统往往需要经过全面的调优甚至要为高性能而做必要的调整如应用架构大型数据库应用系统的调优工作不但需要理论知识 更需要如本文所述的一些将理论综合运用于实践的经验——即国外通常所说的“最佳实践”。转载于:https://www.cnblogs.com/zhengah/p/4627409.html
