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平臺能夠構造全國性的超大型數據庫應用系統； （２）大型數據庫應用系統每每須要通過全面的調優，甚至要爲高性能而作必要的調整（如應用架構）；（３）大型數據庫應用系統的調優工做不但須要理論知識， 更須要如本文所述的一些將理論綜合運用於實踐的經驗——即國外一般所說的「最佳實踐」。