我們在進行gc調優的過程中，經常是發現出現問題後（比如oom或者應用長時間暫停），再進行調優的過程。能不能做到在問題出現之前，就先進行調優呢？讓我們來給gc算算卦吧！
首先，我們需要拿到一些系統執行狀況才能推算出gc的情況，比如：
根據這些資料，就可以開始「算命」了（以下是我針對某個線上應用的推算過程）：
注意在hotspot1.6.0_20版本之前的bug）拿到eden大小，即可推出在當前qps下，每秒鐘系統分配的記憶體大小 將每秒鐘分配的記憶體大小/當前應用的qps量，就推算出當前系統平均每個請求分配的記憶體大小 觀測jstat在每次minorgc後suvivor的大小（取多次中的最大值）+從new晉公升到old的大小（oldgen的前後差值），可以近似的認為此值就是實際需要的survivorspace空間，再將此值增加一定比例（為了留出一些冗餘吞吐量）就得出了需要調優的survivorspace。 根據survivor和eden的比例（-xx:survivorratio）即可算出整個new需要多少空間。 估算出的edenspace大小/(平均每個請求分配記憶體的大小*系統qps峰值)，就可以推出在峰值時大概幾秒鐘會發生一次minorgc。注意如果minorgc發生的頻率過快，可以考慮放大new的空間，這樣就可以讓一些eden中存活的物件多活一段時間，好處是minorgc時應該會**更多的記憶體，減少新物件晉公升到old的可能；壞處是增加每次minorgc的耗時。
這樣就可以將系統的qps和記憶體的分配頻率、分配大小結合在一起，通過一些監控，就可以實現當qps到達一定值時，就要準備做效能調優或對伺服器擴容了。當然，系統的記憶體分配監控可能不是這麼簡單的，系統每個請求的耗時、系統版本更新、外部資源的變更等可能都會導致系統記憶體分配的變化，所以這種「算命」只是針對穩態系統的情況下的一種測算方法。
關於呼叫GC釋放Office程序的方法
1 釋放office excel 程序 方法 一 在同一方法內部呼叫gc 將用到的office 所有物件 到最小物件單元，除了應用程式物件 引用設為null 呼叫應程式物件引用的quit 方法，再將應用程式物件引用置為null 最後呼叫gc.collect 如果最後不將應用程式的物件引用置為null...
PG數量的預估
pg數量的設定牽扯到資料分布的均勻性問題。預設ceph集群中的pg數至關重要，公式如下 結果必須捨入到最接近2的n次冪的值 pg 總數 osd 數 100 最大副本數集群中單個池的pg數計算公式如下 結果必須捨入到最接近2的n次冪的值 pg 總數 osd 數 100 最大副本數 池數pgp是為了實現...
說說JVM的GC功能之一GC演算法的選擇
如果你的應用可以忍受full gc帶來的停頓，throught收集器 即並行gc 能獲得最高的效能。同是他使用cpu和堆的大小都比其他的收集器少 當然不包括serial收集器，它的使用場景太有限 如果無法忍受full gc帶來的停頓，如果可用堆較小，可以選擇cms或g1，如果可用堆較大，建議使用g1...