現在企業已經不再詢問“Java能不能虛擬化”這樣的問題，而是“我們能夠將虛擬化的Java應用平臺擴展到多大？又該如何有效地對其進行調優?”在本書中，頂尖的Java虛擬化專家回答了這些問題，井提供了詳盡的技術信息，你可以將這些技術信息用于任何生產或QA/測試環境。最近9年以來，本書作者一直在虛擬化VMWare自身的企業級應用和300個VMWare重要客戶的項目，這些項目99類型和規模各異——從100AJVM到10 OOO個以上JVM，堆內存從1GB到360GB，其中包括構建在集群JVM上的大數據應用。基于所有這些經驗，作者展示了如何成功地劃分和優化Java工作負載。本書中包含富有極高價值的優化技巧，可以將這些技巧應用于物理環境、虛擬化環境，或者兩者組臺的環境之中。你能夠學到如何臺理地擴展已有的Java應用基礎設施，如何為新的應用提供現代化架構，如何進行系統的基準測試并在各個方面提升虛擬化Java的性能。
VMware公司首席架構師親筆撰寫，全方位解讀在VMWare vSphere上優化企業級Java應用的最佳技術實踐和實用技巧
從計算機硬件體系結構到Java虛擬機的內存管理優化，從內存數據庫的設計到整個應用分層的部署，詳細討論Java平臺虛擬化和調優的原則、策略和技巧，包含大量實例
現在企業已經不再詢問“Java能不能虛擬化”這樣的問題，而是“我們能夠將虛擬化的Java應用平臺擴展到多大？又該如何有效地對其進行調優？”在本書中，頂尖的Java虛擬化專家回答了這些問題，并提供了詳盡的技術信息，你可以將這些技術信息用于任何生產或QA/測試環境。
最近9年以來，本書作者一直在虛擬化VMWare自身的企業級應用和300個VMWare重要客戶的項目，這些項目的類型和規模各異——從100個JVM到10 000個以上JVM，堆內存從1GB到360GB，其中包括構建在集群JVM上的大數據應用。基于所有這些經驗，作者展示了如何成功地劃分和優化Java工作負載。
《大規模Java平臺虛擬化與調優》包含富有極高價值的優化技巧，可以將這些技巧應用于物理環境、虛擬化環境，或者兩者組合的環境之中。你能夠學到如何合理地擴展已有的Java應用基礎設施，如何為新的應用提供現代化架構，如何進行系統的基準測試并在各個方面提升虛擬化Java的性能。
通過閱讀本書，你將學到：
大規模Java平臺相關的性能問題，包括合并、彈性和靈活性
Java平臺中理論限制和物理限制的技術考量
使用VMWare vFabric SQLFire構建水平的內存數據庫，以提升可擴展性和響應時間
使用吞吐/并行GC和并發標記清除（CMS）技術優化大規模Java系統
設計和劃分新的Java環境
從物理化部署環境遷移到虛擬化時，設計并劃分新的大規模Java平臺
為延遲敏感的內存數據庫設計并劃分Java平臺
現實世界中的性能案例：SQLFire與RDBMS對比、基于Spring的Java應用、vFabric SpringTrader、應用層、數據層等
ESXi 3、4.1以及5的性能差異
每類工作負載的最佳實踐：架構、性能、設計、大小劃分以及高可用性
在負載均衡器層、Web服務器層、Java應用服務器層或DB服務器層識別瓶頸
借助esxtop解決復雜的vSphere Java性能問題
有關性能的FAQ：企業級用戶所提問題的答案
The Translator抯 Words 譯 者 序
幾年前，業界對于虛擬化和云計算是否能夠在商業中真正應用還有許多爭論，但目前，云計算和虛擬化已經廣泛應用于蓬勃發展的互聯網領域以及傳統的企業級軟件解決方案之中，軟件開發和部署正在經歷著劇烈的變革。借助云計算的浪潮，一些公司脫穎而出，站在了時代的前沿，這其中就包括VMware—完整的虛擬化解決方案使其成為行業的領導者。
虛擬化在帶來成本節省和運維便利的同時，也帶來了一些新的挑戰，對架構師和運維人員提出了新的要求。在解決了物理設施的虛擬化問題之后，我們的目光可能就會轉移到應用程序本身上來，因為這才是真正為用戶交付價值的關鍵所在。部署在虛擬化環境上的Java應用與物理環境上的應用有什么區別？對不同類型的Java應用如何進行優化？新的數據存儲模式是什么？如何在虛擬化環境下最優化應用部署？對于這些問題，本書都給出了詳盡的解答。本書的作者擁有VMware虛擬化的豐富經驗，所傳授的知識都來源于一線的實戰經驗，相信這些知識對于要進行虛擬化的架構師和運維工程師都會有很大幫助。
在翻譯本書的過程中，深感作者知識領域的深厚和本書涉及內容的廣泛，從計算機硬件體系結構到Java虛擬機的內存管理優化，從內存數據庫的設計到整個應用分層的部署，本書都有介紹，因此，在翻譯時我查閱了許多資料，這對于個人知識領域的拓展也有很大幫助。
在此要感謝關敏編輯所提供的幫助和指導，感謝我的搭檔文建國同學，還要感謝一直以來給我支持和鼓勵的朋友與家人。
盡管在翻譯的過程中，我們力爭達到準確和通暢，但限于水平和時間，書中肯定還有許多不足或紕漏之處，熱忱期待你提出意見，希望本書能對你有所幫助！
張衛濱
前 言 Preface
本書是9年來我在VMware vSphere上運行Java應用的經驗結晶，這些經驗來源于VMware本身以及VMware的眾多客戶。實際上，很多VMware客戶都在VMware vSphere上運行企業級的核心Java應用，并取得了效果更好的總擁有成本（total cost of ownership，TCO）以及服務水平協議（service level agreement，SLA）。我的第一本書是《Enterprise Java Applications Architecture on VMware》（VMware上的企業級Java應用架構），在那本書中很好地闡述了Java虛擬化的主題，其中既包括高層次的架構視角，也包括深入介紹分區大小設置和最佳實踐的技術章節。為了保證第一本書在價格上更為實惠，我將一部分章節放到了第二本書，也就是你現在讀到的這本書中。這兩本書在很多方面都是互補的。在第一本書中有一些高屋建瓴的章節，是針對架構師、工程師以及管理者的，他們第一次考慮虛擬化方案并且可能會問“為什么這樣做”的問題。而本書是關于如何做和做什么才能調整至最佳性能的。
限制第一本書的范圍是個不錯的主意，這樣能讓第一次構建Java虛擬化項目的人快速讀完該書。第一本書出版至今已經有近2年的時間了，從那時到現在，我已經收到了近300條讀者的反饋，這些反饋有助于進一步分析書中所給出的指導建議。其中有些反饋涉及大規模的Java平臺，這些反饋極大地豐富了本書中的細節。本書會詳細討論分區設置以及小規模和大規模虛擬化Java平臺的調優—從100個Java虛擬機（Java Virtual Machine，JVM）到10 000個JVM，JVM堆的大小從1GB到128GB。我最近的經驗以及過去15年來優化Java平臺所取得的經驗都包含在本書中，我將這些經驗進行了總結，以一種最實用并且能夠立即應用于多種Java負載類型的形式進行了闡述。你可以改進本書所給出的建議、部署配置以及垃圾收集（garbage collection，GC）的優化知識來應對糟糕的GC行為，或者在整體上設計并確定Java平臺的規模。本書中所強調的最佳實踐可以應用于物理環境、虛擬化環境或者兩者組合的環境之中。
撰寫本書的動力
在過去的9年中，我在VMware擔任不同的職位以確保所有內部的企業級Java應用都被虛擬化，以此向VMware的客戶展現這種方式所能帶來的收益。就在那個時候，我開始相信我們在生產環境下根據試驗數據所得到的最佳實踐應該分享給VMware社區。我收到了很多的反饋，要求我將在VMware上運行企業級Java應用方面所學到的經驗以及獲取成功的各種技巧進行文檔化。這就是寫作第一本書《Enterprise Java Applications Architecture on VMware》（https://www.createspace.com/3632131）的動力。
延續了寫作第一本書的動力，本書（也就是第二本書）主要關注要調整什么、能調整到什么程度以及大型虛擬化Java平臺該是什么樣子的。實際上，第一本書的內容回答了“為什么虛擬化”以及“要做什么/如何來實現虛擬化”的問題。而本書探討了“你能虛擬化多大規模的應用以及你對平臺能夠優化到什么程度”。
寫作第一本書是非常令人興奮的，因為我們試圖讓VMware的廣大用戶群了解Java虛擬化是完全可行的并且能夠帶來很明顯的收益。在這本書中，我們將為一些客戶提供幫助，這些客戶的訴求可能是“現在請幫助我們將規模提升到一個新的水平”。在過去的2年間，我們幫助客戶虛擬化了很多大規模的JVM平臺，有些甚至達到10 000個JVM，有些涉及大數據平臺領域（在一組集群JVM之中，將多個TB的數據存放于內存之中）。在你深入學習本書之前，需要記住的一點是：盡管本書中展現了很多的最佳實踐，這些實踐代表了最佳的配置指導，但是這些并不是強制性的要求。按照經驗，我們發現大多數企業級Java應用的虛擬化很容易，并不需要擔心太多的特定配置。實際上，在各種類型的企業級產品化應用之中，Java應用是進行虛擬化的最佳候選，因為它很容易取得成功。通過分享我們的經驗，希望能夠幫助你避免在虛擬化大規模Java平臺時我們曾經遇到過的陷阱。
為了闡述在虛擬化環境中部署Java平臺有多么棒（同時也為了消除虛擬化平臺會成為問題的誤解），我們構建了同時適用于物理化與虛擬化環境的最佳實踐。在設計上，本書包含了針對物理化和虛擬化Java平臺的最佳實踐，所以能夠幫助讀者在進行虛擬化之前，糾正他們在物理化Java平臺中所遇到的問題。當然，這并不是強制性的要求，在遷移到虛擬化的時候，客戶可以選擇繼續保留物理化Java部署時的遺留問題。但是，他們至少能夠意識到其物理化Java平臺在設計和部署上的不足，這是他們希望將來要進行修正的。
這樣的經歷是很重要的一個歷練過程，能夠讓我們清楚地認識到：問題實際上存在于客戶自己的物理化環境中。因此，客戶能夠理解維護物理化Java平臺上遺留問題的成本。例如，我們經常發現很多Java物理化平臺有著糟糕的架構和錯誤的拓撲結構，很多有著上千個混亂且不必要的JVM。當我們與這些客戶交流時，不管他們是將Java應用部署在物理環境中還是遷移到虛擬化環境中，我們都會帶領他們了解這些最佳實踐并確保這些環境要進行正確地規模劃分和調優。再強調一遍，客戶可以忽視我們所給出的建議，對代碼和平臺不做太多的修改或變更就將遺留的Java物理化平臺部署到對等的虛擬化環境之中。但是，在遷移到虛擬化平臺時，客戶最近越來越認識到我們（以及其他人）所給出的最佳實踐對于提升Java部署范式的價值。
我們學到的經驗教訓分為以下幾類：
在生產環境下，肯定會出錯，出錯只是一個時間問題。所以，你必須要一絲不茍地考慮哪里可能會出錯并制定前滾（roll-forward）和回滾（rollback）計劃。這個計劃中的練習過程有助于進一步強化QA（質量保證）的測試計劃。要注意的一點是，這并不是虛擬化環境所特有的。實際上，不管你處理的是物理化的還是虛擬化的基礎設施，這都是同等嚴格的需求。但實際情況是，虛擬化為你提供了一種快速處理問題的機制（與之形成對比的是，在物理化場景下，你所能取得的靈活性會受到一定的限制，你必須圍繞你所擁有的計算資源規劃靈活性）。
當進行虛擬化的時候，企業級Java應用是最容易取得成功的。
每個人都在Java的各個分層中工作，這些分層了形成各種筒倉（silo），人們在技術和組織流程方面說著不同的術語。顯然這是老式物理化（非虛擬化）范式下的做法，這些技術和組織上的筒倉是過去10多年來所形成的。但是，在VMware上虛擬化Java時，很重要的一個方面就是跨團隊協作，它會驅動很多團隊互相交流以促成最佳的設計。來自開發和運維的團隊會多次坐到桌邊進行討論。
客戶有時候會為其環境中遺留的問題進行辯解。由此導致的結果就是，客戶需要付出額外的成本來管理物理環境中龐雜的JVM，如果不進行及時補救，這些成本也將會帶到虛擬化系統中。例如，你真的需要5000個具備1GB堆空間的JVM嗎？它們能夠進行合并嗎？它們絕對可以合并，我們將向你展示如何通過減少許可證成本以及提高管理效率（因為你需要管理的JVM更少）實現費用的節省。
性能問題。客戶經常盲目地將所有問題都歸咎于虛擬化或GC的問題。但實際上，虛擬化并不是什么問題，而GC有時候的確會成為問題。如果存在GC問題，這并不是虛擬化所特有的，實際上這樣的問題通常在物理化部署環境中同樣存在。
在物理化Java平臺中，使用大內存數據庫是否可行（確實可以達到1TB的內存集群）？絕對是可以的，如果主要的目標是不惜任何代價實現事務，同時還要實現盡可能快的速度，那么對你來說這是正確的架構。我發現很多客戶對此持懷疑的態度。他們在對這些類型的環境進行規模劃分時并沒有考慮底層的平臺，對于他們來說這是一個糟糕的開始。當對這些數據平臺進行規模劃分（稍后會進行討論）時，你必須關注服務器的機器架構。在有些客戶那里，我看到另外一個糟糕的實踐就是他們試圖將環境劃分為30個左右的JVM。這并不是正確的方式，因為讓眾多JVM相互之間以較高的速度頻繁交流可能會導致整體延遲更多。顯然，這些都是對延遲敏感且依賴內存（memory-bound）的負載，使用數量更少且內存更大的JVM部署模式所取得的效果會更好。如果比較兩種不同部署方式的內存數據庫性能，其中一種使用30個JVM，另一種使用8個更大的JVM，你會發現8個更大JVM的配置方案會更好一些。當然，這里要提示的一點是，更大的JVM要針對NUMA進行正確的規模劃分，并且要進行恰當的GC調優。
當虛擬化的時候，大的內存數據庫方案真的可行嗎？在過去的幾年間，我們發現在客戶中有一種日漸增長的趨勢就是虛擬化Java應用服務器。具體來講，就是具有幾千個JVM的大規模平臺正在被虛擬化。有一種特殊的負載類型，那就是內存數據管理系統，它需要TB級別的內存并且對延遲是敏感的。對于這些內存集群，我們發現盡管JVM的數量更少了，但它們會有較大的堆空間，通常JVM的大小是8～128GB（JVM的數量通常會少于12）。當然，12這個數字本身并沒有什么魔力，少的話可以是3個，而多的話可以達到30個。但是，你所擁有的JVM越多，在延遲性方面出現風險的可能性就越大，這是因為會出現額外的網絡傳輸。在本書后面，你會學習如何對這種負載進行規模劃分和調優。
很多Java應用開發人員很了解開發過程，他們知道如何編寫Java代碼以及如何對JVM進行調優。但是，這些信息通常只存留在開發人員那里，并沒有分享（或傳遞）給應用的管理人員。通常，運行Java平臺所需要的技能在開發人員和管理人員之間是分割的，沒有一個人能夠完全理解這兩個方面。但是，這種孤立式的理解正在發生著變化，因為有更多的人開始去理解如何編寫和部署Java代碼、調優JVM并認識虛擬化的各個方面和復雜的服務器硬件架構。所以本書的另外一個目標就是，當讀者學習這些技能時，鼓勵他們遵循這樣的職業發展路徑。
我非常真誠地希望本書能夠幫助那些具有Java開發、基礎設施運維以及虛擬化背景的人。你可以將本書作為應對日常情況的指導，也可以作為構建Java平臺架構策略的幫助手冊。
預備知識
本書假設讀者已經在整體上了解Java、JVM GC、服務器硬件架構以及虛擬化技術。這里的知識都是關于運行大規模Java平臺的。在深入學習本書的內容之前，你可能希望先學習一下虛擬化，但是大多數Java的高級專家借助本書就足以掌握關于虛擬化及虛擬化Java應用的知識。實際上，通過回答下面的這個問題就能掌握繼續閱讀本書所需的虛擬化背景知識。這個問題是一位剛剛接觸虛擬化的人某一天提出的：“Java是不是能夠獨立于操作系統及hypervisor？”
本書假設讀者已經掌握了一些關于Java語言特別是JVM架構的背景知識。本書盡可能地概述了JVM架構以及具體的調優方法，但是本書不能代替專門的JVM優化圖書。我只想說，剛剛接觸JVM調優的vSphere管理員能夠從本書中學習到足夠的知識，以便于他們與從事Java的同事進行技術交流。除此之外，vSphere和Java管理員可以使用并修改本書的調優建議，并將其應用于自己的環境之中。JVM調優建議的各個章節在編寫上比同類圖書更為簡單易懂，目的是為了讓vSphere和Java管理員能夠快速了解并有效地運用設計和優化策略。眾多運行Java應用的VMware客戶使用本書中所討論的優化參數并立即得到了性能方面的提升。
你首先需要知道些什么
你在閱讀本書就意味著你正在修正你的Java平臺。可能你已經得出這樣的結論，那就是Java平臺的調優不能被忽略或輕視。但是，即便你剛剛涉足VMware虛擬化或者是在物理化系統中對Java進行調優，那么本書也是適合你的。作為補習內容（對于剛剛接觸這些領域的人來說也可以作為入門介紹），以下的章節簡要介紹了虛擬化與大規模Java平臺調優相關的重要概念。
4GB的Java堆是不是相當于新的1GB的Java堆呢，為什么
在過去的2年中，我參與了超過290個客戶電話和研討會，了解到很明顯的一點是，運行在Java平臺上的40%的工作負載都部署到1～4GB的JVM上。我進而發現有大量小于1GB的JVM，大約占到了我接觸客戶的另外40%。而剩余的20%范圍在4～360GB之間。是的，這個360GB的JVM是一個監控系統，它不能夠水平擴展，所以客戶只能使用一個JVM。盡管這聽起來有點令人難以置信，但這確實是Java產品化平臺的現狀。不過，使用1GB堆的JVM會導致JVM實例數量的膨脹，在自身的管理方面這會成為令人頭痛的問題。例如，你可能希望提供共計1TB的堆空間，如果你只使用1GB的JVM堆，那么這就意味著你有幾千個JVM實例。這可能帶來什么問題呢？你是否能夠通過250個4GB的JVM得到1TB呢？當然可以，但因為在你的組織中，依然存在來自于古老的32位JVM的遺留規則，所以你還得繼續使用小于1GB的JVM。更為現實的原因是，人們廣泛認為更大的JVM會導致更長時間的GC停頓。這種說法并不完全正確，但也并不能說完全錯誤。的確，這會產生更大的停頓，但是隨著64位JVM以及CMS（concurrent mark-sweep）GC的最新發展，規模更大且停頓時間更少的JVM時代已經到來。不僅GC更好了，底層的服務器硬件也能夠更好地支持4GB堆空間了。實際上，4GB是一個獨特且具有魔力的數字，因為在64位的JVM中，為了節省內存的使用，JVM會自動將4GB的堆空間視為32位的地址空間。這樣做之所以可行是因為32位的地址范圍就是在4GB之內。實際上，使用-XX:+UseCompressedOops參數的JVM可以應用于高達32GB的Java堆空間之中。
在讀完本書之后，你將會認識到適合更大JVM的可選方案和應用負載是存在的。顯然，我并不是倡導每個人都使用更大的JVM，但是4GB的JVM現在真的不算大了。需要記住的是，我倡導的是更為合理的JVM數量，盡管這可能意味著增加堆的大小。另外需要記住的是，如果有供應商跟你說從32位的JVM遷移到64位的JVM時會犧牲性能的話，那么這是完全不對的。我們的壓縮優化經驗在很大程度上駁斥了從32位JVM遷移到64位JVM會導致性能下降的說法。例如，可以考慮這樣的情景，為了提供1TB的服務，可以使用250個JVM，也可以使用1000個JVM。問一下供應商，如果不用運行750個JVM會節省多少成本（因為你將1GB的JVM堆遷移為4GB的JVM堆）。節省的成本可能會包括不再用到的750個GC周期，還有節省下來的CPU內核。因為不再需要為額外的許可證支付費用，在這方面你也能節省費用。
本書中后面的章節將會深入討論各種規模的JVM以及在什么情況你應該選擇某一種方案而不是另外的可選方案。
Emad Benjamin，VMware公司首席架構師，過去9年來一直關注VMWare vSphere、vFabric GemFire和SQLFire環境上的Java。Benjamin有20余年IT行業經驗，其中包括16年使用Java的經驗。他在虛擬化和Java的交叉領域有著深厚的背景知識，曾參與撰寫《Enterprise Java Application Architecture on VMware》，并曾在VMWorld、SpringOne、UberConf和NFJS上發表過與Java虛擬化相關的演講。
張衛濱，畢業于天津大學，現為軟件工程師、InfoQ社區編輯，熟悉Java語言，對Java開源框架（如Spring、Hibernate、Eclipse等）有一定的研究，目前主要致力于企業級軟件的開發以及流程優化。譯著有《Spring實戰（第3版）》《Java應用架構設計：模塊化模式與OSGi》和《Spring Data實戰》。
文建國，系統架構設計師、高級項目經理、PMP，精通Spring等優秀開源技術在企業中的應用，主要研究方向為云計算、大數據、業務基礎平臺、分布式等技術。他曾參與中國電信ITSP3.0技術架構規范編寫，有著多個大型云計算項目的架構和管理經驗。他目前致力于移動互聯網社區O2O平臺的架構和研發。譯著有《Spring Data實戰》。
譯者序
前 言
第1章 大規模Java平臺簡介1
1.1 大規模Java平臺的分類1
1.2 大規模Java平臺的趨勢與需求2
1.2.1 計算資源合并2
1.2.2 JVM實例合并2
1.2.3 彈性與靈活性3
1.2.4 性能3
1.3 大規模Java平臺的技術因素3
1.3.1 Java平臺在理論和實際中的限制3
1.3.2 NUMA7
1.3.3 在生產環境中，最為常見的JVM規模13
1.3.4 JVM和VM的水平擴展與垂直擴展13
1.4 本章小結17
第2章 現代化可擴展的數據平臺18
2.1 SQLFire的拓撲結構20
2.1.1 客戶端/服務器拓撲結構21
2.1.2 端到端拓撲結構23
2.1.3 冗余區23
2.1.4 全球的多點拓撲結構23
2.2 SQLFire特性25
2.2.1 服務器分組27
2.2.2 分區29
2.2.3 冗余31
2.2.4 位置協同32
2.2.5 磁盤持久化33
2.2.6 事務35
2.2.7 緩存插件39
2.2.8 監聽器41
2.2.9 writer43
2.2.10 異步監聽器44
2.2.11 DBSynchronizer46
2.2.12 SQLF命令與DDLUtils48
2.3 Active-Active架構與現代化數據平臺 49
2.4 本章小結52
第3章 大規模Java平臺調優53
3.1 GC調優方法58
3.1.1 步驟A：新生代調優58
3.1.2 步驟B：老年代調優62
3.1.3 步驟C：Survivor 空間調優63
3.2 本章小結65
第4章 設計和劃分大規模Java平臺66
4.1 為虛擬化大規模Java平臺設計和劃分新環境66
4.1.1 步驟1：建立生產環境下的負載Profile67
4.1.2 步驟2：建立基準67
4.1.3 步驟3：劃分生產環境77
4.2 劃分vFabric SQLFire Java平臺：第二類工作負載78
4.2.1 步驟A：確定實體分組78
4.2.2 步驟B：確定數據Fabric的內存大小81
4.2.3 步驟C：確定模板VM和JVM的大小以及所需的vFabric SQLFire成員數量84
4.2.4 理解HotSpot JVM內部的內存分區 85
4.2.5 理解劃分大型VM和JVM時NUMA的影響86
4.2.6 vFabric SQLFire大小劃分樣例90
4.3 本章小結96
第5章 性能研究97
5.1SQLFire和RDBMS性能研究97
5.1.1性能結果98
5.1.2 結果總結 101
5.2 Olio工作負載運行在tc Server和vSphere上的性能研究101
5.3 SpringTrader性能研究105
5.3.1vSphere應用層和數據層配置107
5.3.2 SpringTrader性能研究結果 110
5.4 ESXi 3、ESXi 4.1和ESXi 5的性能差異111
5.4.1CPU調度改進 111
5.4.2內存增強112
5.5vSphere 5性能提升113
5.6 本章小結114
第6章 最佳實踐115
6.1vSphere上企業級Java應用的最佳實踐（第一類）117
6.1.1VM規模大小以及配置的最佳實踐117
6.1.2VM vCPU的最佳實踐118
6.1.3 VM內存劃分的最佳實踐119
6.1.4 VM時間同步最佳實踐122
6.1.5 垂直擴展性的最佳實踐122
6.2 水平可擴展性、集群以及池的最佳實踐123
6.2.1 分層之間配置的最佳實踐124
6.2.2 vSphere的最佳實踐126
6.3 SQLFire最佳實踐以及vSphere上SQLFire的最佳實踐（第二類JVM工作負載的最佳實踐）128
6.3.1 SQLFire最佳實踐129
6.3.2 在vSphere上vFabric SQLFire的最佳實踐131
6.4 第三類工作負載的最佳實踐136
6.5 GC策略選擇138
6.5.1 IBM GC可選方案139
6.5.2 Oracle jRockit GC策略140
6.6 本章小結140
第7章 監控與故障排除141
7.1 開啟請求支持的Ticket142
7.2 通過vCenter收集指標143
7.3 借助esxtop排查vSphere問題的技術146
7.4 Java問題排除指導148
7.4.1 排查Java內存問題150
7.4.2 排查Java線程競爭的問題151
7.5 本章小結152
附錄FAQ153
術語表170
新書資訊