中間件體系結構之掌握多層調整
2024-07-21 02:33:37
供稿：網友
新的體系結構帶來新的挑戰
Edwards 認為，從客戶/服務器向多層體系結構的改變影響了數據庫性能優化和調整的幾個重要方面 — 兩個最重要的方面是資源治理以及數據庫工作負載的跟蹤。
暗藏的資源泄漏
Edwards 解釋說：“在擁有專用 Oracle 服務器進程的傳統客戶/服務器環境中，保護資源的方法完全不同。Oracle 會話啟動和停止過程所在的應用程序連接具有非常有限的生命期。因此，假如存在一些效率較低和較差的資源治理，比如應用程序無法關閉游標或應用程序有內存泄漏 — 那么，當連接斷開時，這些都被自動清除，泄漏及低效率的影響和持續時間不太明顯。在多層世界里，您傾向于擁有一個由應用服務器多次重復啟動和使用的連接池。因此，假如有游標或內存泄漏，則它們會增加和持續存在，并不會消失。資源泄漏 — 如連接泄漏、內存泄漏和游標泄漏 — 具有明顯的影響，并可能最終導致產品應用程序或環境發生故障。”
Edwards 經常被召來，嘗試解決非常重要的硬件服務器、數據庫或應用程序由于這種泄漏而無法正常工作的情況。他回憶道：“有一次，一個大型的產品級硬件服務器 — 它支持多個全天候工作的 oracle 數據庫 — 由于 PGA 內存泄漏而反復崩潰。數據庫應用程序和配置導致操作系統耗盡了可用的虛擬內存（物理內存和交換空間） — 我們在一個 oracle 實例中發現了內存泄漏，大小總計超過 45 吉字節！在另一個案例中，連接的泄漏使應用服務器的連接池不可用；應用程序中不良的連接治理導致應用服務器的多個實例被制約并掛起。而在另一個案例中，應用程序在不經常執行的代碼體中具有大量游標泄漏。這些泄漏的最常見結果是單個連接數超出游標的最大數量 — 但有時整個 Oracle 實例會有危險。”
Edwards 認為，資源泄漏的潛在影響非常嚴重。“使其具有潛在危險的部分原因是，在測試或監視過程中很難發現它們，非凡是在它們與容量相關的情況下。它們往往會令人難以覺察地潛伏著，緩慢地侵蝕系統的寶貴資源，直到它們忽然膨脹堵塞，造成災難性后果。”
跟蹤損傷
跟蹤和配置是調整的另外方面，Edwards 認為它們已受到體系結構變化的巨大影響。
他指出：“在客戶服務器體系結構中（尤其是 Oracle 專用的服務器環境），會話與專用服務器進程具有獨占的、一對一的關系。因此您可以打開跟蹤功能，操作工作負載，關閉跟蹤功能，然后從一個進程的一個跟蹤文件中查看步驟的順序 — SQL。您可以實際查看語句所執行的順序。您知道該跟蹤文件中只有您的語句，并且不必通過多個跟蹤文件來重建您的會話。識別要跟蹤的會話也更輕易，因為能夠以特定的、可識別的 Oracle 用戶名來執行每個用戶的會話。”
他提示說：“在具有連接池的多層世界里，情況完全不同。應用程序本身并不總是明確地控制工作單元或者治理其自身的連接。應用程序端很少關注會話 — 因此，當您要進行跟蹤時，您不知道是什么服務器進程將會獲取該跟蹤的輸出。您不知道在哪個跟蹤文件中 — 經常有很多跟蹤文件 — 獲取您的應用程序線程。此外，在一個進程的跟蹤文件中，您可能擁有來自多個用戶會話的步驟。因此，很難辨別哪些語句來自您自己的應用程序以及它們以何種順序執行。更糟的是，所有的連接 — 有時同時有數百個連接 — 可能是以相同的 Oracle 用戶（應用服務器用戶）來執行 — 而不是以真實的、可識別的最終用戶來執行每個連接。因此，您不能簡單地識別和區分出需要檢查的會話。”
Edwards 指出，這些復雜性給預見性的應用程序監視和容量計劃造成了困難，并影響對已發現性能問題的處理。“假如您的最終用戶說：‘咦，我的某些特定功能好象運行很慢。’假如沒有數據庫以外的補充信息，很難進行調查，并且很難了解該功能當前正在哪個連接上執行和涉及到多少個語句 — 而且難以判定問題的根源。SQL 效率不高？數據庫或應用服務器有問題？假如偶然有爭用和某種類型的等待事件，則可能很難進行識別和歸類。判定性能為何沒有達到最佳的原因已經成為復雜、曲折的過程，并且您必須使用更多的手段。”
調整的提示和技巧
Edwards 認為，有效調整多層體系結構的要害是以下三項策略：采取全局的觀點、使用科學的方法論、采用從 SQL 開始工作的調整策略。
全局的方法
Edwards 說，由于多層體系結構中有許多級，常見的調整錯誤是每次只關注一級，而忽視了全局。“您需要具有更普遍、更全面的觀點，因為您需要能夠解釋最終用戶操作的時間。各層間通信的等待時間經常成為問題，并且這種問題不輕易測量、隔離或再現。我們可以獨立查看每一層 — 應用服務器層、RDBMS 層、客戶端層 — 而且可能每一層在其自身范圍中都表現得很高效，但最終用戶的體驗仍然很糟。因此，您必須能夠在所有不同層中以及在層間通信方面監視和估計時間。”
查看全局可能需要將不同小組的人們集合在一起，以便他們能夠增加相互的了解。
Edwards 說：“在大多數機構中可能出現的情況是，DBA、UNIX 或系統治理員團隊和網絡團隊都屬于不同的組，他們沒有必要了解其他人的事。操作系統工作人員不了解數據庫工作負載，而數據庫工作人員不了解操作系統的資源。網絡團隊也有自己單獨的領域。我認為您確實需要全面了解 I/O、內存、CPU 以及網絡的情況。您需要能夠解釋所有這些信息，了解它們，知道何時飽合或何時出故障，并知道選擇什么方法來增加資源或減少問題。您越是能夠使不同的團隊在這方面協同工作并相互了解，效果就越好。”
科學的方法
Edwards 強調的調整的另一個方面是采用科學的方法。
他說：“您必須擁有評估性能問題并對其進行量化的經驗化科學方法學，而不是基于假設或直覺而采取行動。所包含的部分原因是確保您得益于歷史方面的性能情況：工作流狀況如何、已經完成了多少工作、資源消耗程度有多大。假如您沒有應用程序的歷史資料，您就不了解如今情況的相對優劣，以及它們與以前的情況有多少差別。”
在查看歷史數據時，Edwards 建議在具有工作流時應該主要關注工作流的模式。“您需要建立使工作流可猜測并具有一致性的方法。是否天天都有非常相似類型的指令事務，或者事務是高度即席的查詢，其工作流的復雜性變化很大？在我的經歷中，J2EE 和多層應用程序可能有一定程度的可猜測性、指示性，并且它們經常在本質上是事務型的，因此研究歷史數據很有用處，用于建立將會洞察調整過程和容量計劃的模式。”
SQL 居先的策略
在開始進行調整過程的實際步驟時，Edwards 果斷主張從 SQL 開始。
他承認：“要調整環境，您總有事可做。如更改 I/O 規劃、更改高速緩存的內存結構等等。但是當您更改 SQL 時，可以顯著影響工作負載，假如您用相反方式來做，結果將完全相反。90％ 的時間里，您只需通過調整 SQL 本身，即可顯著減少資源的消耗，從而改變資源需求的情況（內存、cpu 和 I/O）。”
Edwards 解釋說，從數據庫端來看，多層體系結構中調整 SQL 的基本目標和方法與客戶/服務器方式沒有顯著差別。
他指出：“在這種情況下，客戶端不是 SQL 形式的應用程序或者 Visual Basic 應用程序和 C 程序，而恰恰是應用服務器本身。但是它仍在進行 SQL 調用，或者通過 SQL*Net 或者通過 JDBC 瘦客戶端。我們需要在數據庫端使用的方法學與此很相似。我們需要監視正在運行什么語句，并查看哪些語句成本最高（資源密集）。我們需要查看總計的資源消耗，查看我們是否當時被限制在某些點 — 內存、CPU、磁盤或網絡 — 以及是否發生爭用。”
為找出正在運行的成本最高的 SQL，Edward 從語句級數據收集開始。
他說：“完成這項工作有許多方法，或者通過手工創建的查詢，或者使用 STATSPACK 或那些收集當前所執行 SQL 的統計信息的第三方實用工具。您可以根據邏輯 I/O、物理 I/O、分析與執行的比率和計數以及其他數值，找出成本最高的 SQL。您可以查看 I/O 的大小和數量、讀寫比率以及內存的數量。但是，假如有一個我可以看作 SQL 成本代理的因素，那么我查看它執行的邏輯 I/O 的數量 — 對我來說，這是可以用于了解特定語句相關影響的最有指導意義的單個量度。”
Edwards 說，在識別出哪些 SQL 語句的成本最高以后，就應該設置調整目標的優勢級。“我們看著一條語句并提問：它是每月運行一次還是每年運行一次，或是天天運行數百次？您必須提供某種加權因素，以評判需要滿足哪些語句 — 這些語句在形成歷史觀點方面很有用處。”
Edward 建議，在找到需要調整的 SQL 語句后，在可能的情況下應手動調整這些語句 — 這可能意味著完全優化它們。“經常出現的情況是，您需要退回去并且說：‘好吧，現在的總體業務目標是什么？’假如您正在調整一個包括十步的過程中的某個步驟，而您實際上可以將它壓縮為包括兩步的過程，則全局觀點會為您節省很多時間和精力。”盡管調整高成本 SQL 是 Edwards 最優先考慮的，但他提示并不是所有的高成本 SQL 都可以更改。“不能更改的 SQL 可能是硬編碼應用程序中的 SQL 或者是由 EJB 容器或類似工具生成的 SQL。在這種情況下，您可能希望更改數據或創建其他結構，這些結構能夠導致執行計劃的更改并具有更高的效率。”
其他調整策略
Edwards 的調整策略超越了 SQL 調整，他認為這時候“無法再進一步實質性地調整 SQL 工作負載 — 意味著應用程序的工作負載已經穩定。這是服務器環境調整 — 數據庫、硬件和操作系統 — 最有效的時候了。”
在這種情況下，進行索引似乎是顯而易見的選擇，但 Edwards 建議仔細思考進行索引是否是對所懷疑問題的正確選擇。
