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

轉載于:https://www.cnblogs.com/zhengah/p/4627409.html

總結

以上是生活随笔為你收集整理的Sybase数据库应用系统调优的五大领域的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。