Sybase数据库应用系统调优的五大领域

Sybase数据库应用系统调优的五大领域

2011/3/14/13:49来源：慧聪it网

    本 文以“某大型商业银行的网上银行系统”这一很具备典型意义的企业级大型Sybase数据库应用系统为例，涉及了数据库应用系统调优的五大领域：压力测试、 应用端调优、服务器端调优、系统平台层的优化、应用架构的优化，详细介绍了做者在项目开发过程当中曾经遇到的各类问题及其解决办法。本文经过对“企业级 Sybase数据库应用系统的性能调优的最佳实践”的探讨，从而为这类性质的工做提供了具备广泛指导意义的参考。

    1.项目背景与特色

    该应用系统是在总结前一代网银系统的经验教训的基础上，于2008年开始完全从新设计、开发的。

    技术上，它从J2EE技术架构转向.NET架构，大幅度提升了应用程序的开发效率、运行效率，改善了最终用户的实际体验 （UserExperience）；业务上，同时推出了“我的网银”、“企业网银”、“手机银行”等，使该行在非传统业务渠道上实现了跨越式发展，迅速赶 上并超越了同行；产品上，从SybaseASE12系列产品升级到15系列产品，以便充分利用其高性能、高可靠性特征。

    2.系统逻辑架构

    如图所示，该系统共分3个层次，有数个关键组件——

    接入层（AccessLayer）：包括防火墙（Firewall）、网络负载均衡设备（LoadBalancer）等；

    应用及管理层（Application&ManagementLayer）：包括静态网页服务器 （StaticPagesHTTPServers）、面向不一样业务的多组应用服务器（GroupedApplicationServers）、证书管理服 务器（CA&LDAP）、Sybase数据库服务器、各类系统管理监控工具等；

    后台接入：主要是接入各类后台系统的网关（BackendGateways），如主机交易网关等。

点击此处查看所有新闻图片

    3.系统的业务量

    在衡量网上银行的业务交易量时，一般用两类业务指标：一类是帐户类交易，即涉及用户帐户核心信息（特别是帐户余额）的交易，如“交 易明细查询”、“转帐”、“缴费”等；另外一类是辅助交易，如“经常使用关联帐户/收款方管理”、“证书/口令管理”、“理财产品信息”、“用户定制菜单管理” 等等。

    在本项目中，咱们用以下的系数关系描述系统的业务量：若是“帐户类交易量”为１，则“辅助交易量”为0.6，SybaseASE数据库系统的总业务交易量为1.6。若是不特别指明，本文主要使用“帐户类交易量”（“总业务交易量”）的表达方式。

    该项目的几个关键点列示以下：

    2009年7月刚刚上线时，其业务交易量约为300万笔/天（480万笔/天）；

    2009年年末时，其业务交易量增加到600万笔/天（960万笔/天）；

    2010年5月初，达到1000万笔/天（1600万笔/天）；

    2010年10月初，达到1500万笔/天（2400万笔/天）；

    将来2年内的业务压力预计是天天3000万笔（4800万笔/天），该目标极可能在2011年末提早达到。

    

    4．Sybase数据库应用系统调优的五大领域

    （1）压力测试领域

    从笔者观察到的行业现状看，在应用系统上线前，一般会有不一样形式的功能测试；但压力测试的普及度很低，即便有压力测试，也一般不能 很好地预测将来的系统表现。其形成的客观后果是：大多数大型数据库应用系统必定会在实际运行过程当中发生性能问题，而且这种性能瓶颈一般过早地出现，没有能 够充分发挥系统软硬件资源的潜能。

    究其缘由，除了要强调压力测试对于大型系统的必要性，还要改进压力测试的方法。我认为，在压力测试领域应该注意３个关键问题，即“业务指标的肯定策略”、“业务压力的模拟策略”、“性能评测指标的选取策略”。

    (2)数据库应用端的调优

    要进行数据库应用系统的调优，最好的着力点是从数据库应用端出发，找出实际运行效率低下的应用模块/ＳＱＬ。

    传统的定位方法是：在应用逻辑中、或在应用模块调度/总控程序中加入“测控模块/语句”，衡量每一个模块/语句的“入/出时间点”， 从而获得其执行时长。这种方法容易理解，常在系统调试阶段使用，也经常使用于层次化应用（LayeredApplication）环境中的层间隔离。但其缺点 是，这种方法会加剧应用开发团队的负担，不容易运用于已经上线的生产系统中。

    对于数据库应用中的SQL模块/语句方面的性能问题，咱们推荐具有网络嗅探（NetworkSniffing）机制的工具，如美国 WhiteSands公司的ProActiveDBA。它可以借助于网络监听，在绝不影响应用系统的状况下，计算出每一个SQL语句/模块的“入/出时间 点”，从而获得其执行时长，找到有效率问题的部分。

    可是，按照其实际执行时间来排序、筛选的上述方法，并不必定能找出全部可能构成系统瓶颈的SQL。还有另一种情形须要注意——某 些SQL，因为各类缘由（例如，其涉及的数据较少、逻辑简单等），其单独的执行时间并不很长、很不起眼，可是其执行频度/总次数特别多，其累计的内存I /O（Sybase称其为逻辑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.5，ASE15须要更多的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倍！

    由此说明，虽然SAN（StorageAreaNetwork）与LVM带来了不少益处，但也应当仔细规划。最多见的是那种 “StripeEverythingEverywhere”的存储设计模式，即把全部数据库对象都打散在逻辑卷（LV）上、LV打散 （stripping）在由数个PV组成的diskgroup上、一个SAN存储及其I/O通道为多个机器上的多个应用共享。这种模式的最大不足是：多个 机器上的多个应用系统之间经过共享的SAN相互影响，难以进行性能调优，难以实现灾难恢复（DisasterRecovery）。对于性能要求比较高的超 大型数据库应用系统，咱们仍是建议配置专用的硬件，不管是SAN、网络等等。

    (4.2)NAS存储的调优

    近年来，NAS（Network-AttachedStorage）存储被愈来愈普遍地使用，由于与SAN相比，它成本更低、文件共享更容易、对客户端要求更少。

    本人曾经有一个难以忘怀的经历。某个工做日的下午４点，客户的Sybase数据库系统发生故障，6G的事务日志即将被用完且没法清除，全部数据修改交易即将被挂起！

    事实说明，NAS不一样于SAN、DAS（DirectAttachedStorage），它毕竟不是主机的直连存储设备，且一般没 有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环境下。它是轻量级的、非事 务性的（lightweight&nontransactional）。

    结语：

    本文的意义在于：（１）该项目的客观实践再次证实了借助于Sybase/UNIX平台能够构造全国性的超大型数据库应用系统； （２）大型数据库应用系统每每须要通过全面的调优，甚至要为高性能而作必要的调整（如应用架构）；（３）大型数据库应用系统的调优工做不但须要理论知识， 更须要如本文所述的一些将理论综合运用于实践的经验——即国外一般所说的“最佳实践”。