es 調(diào)整gc

調(diào)優(yōu)垃圾回收與任何其他性能調(diào)優(yōu)活動沒有什么不同。

您需要確保您了解當(dāng)前的情況和所需的結(jié)果，而不是因?yàn)閷?yīng)用程序的隨機(jī)部分進(jìn)行調(diào)整而產(chǎn)生了誘惑。 通常，只需執(zhí)行以下過程即可：

陳述您的績效目標(biāo)

運(yùn)行測試

測量

與目標(biāo)比較

進(jìn)行更改并返回運(yùn)行測試

重要的是，可以設(shè)定和衡量目標(biāo)的三個方面都與性能調(diào)整有關(guān)。 這些目標(biāo)包括延遲，吞吐量和容量，理解，我建議您閱讀垃圾收集手冊中的相應(yīng)章節(jié)。

讓我們看看如何開始研究設(shè)定和實(shí)現(xiàn)這些目標(biāo)的實(shí)際情況。 為此，讓我們看一個示例代碼：

//imports skipped for brevity public class Producer implements Runnable {private static ScheduledExecutorService executorService = Executors.newScheduledThreadPool(2);private Deque<byte[]> deque;private int objectSize;private int queueSize;public Producer(int objectSize, int ttl) {this.deque = new ArrayDeque<byte[]>();this.objectSize = objectSize;this.queueSize = ttl * 1000;}@Overridepublic void run() {for (int i = 0; i < 100; i++) {deque.add(new byte[objectSize]);if (deque.size() > queueSize) {deque.poll();}}}public static void main(String[] args) throws InterruptedException {executorService.scheduleAtFixedRate(new Producer(200 * 1024 * 1024 / 1000, 5), 0, 100, TimeUnit.MILLISECONDS);executorService.scheduleAtFixedRate(new Producer(50 * 1024 * 1024 / 1000, 120), 0, 100, TimeUnit.MILLISECONDS);TimeUnit.MINUTES.sleep(10);executorService.shutdownNow();} }

該代碼將提交兩個作業(yè)，每100毫秒運(yùn)行一次。 每個作業(yè)都模擬具有特定壽命的對象：它創(chuàng)建對象，讓它們離開預(yù)定的時間，然后忘記它們，從而使GC回收內(nèi)存。

在使用以下參數(shù)打開GC日志記錄的情況下運(yùn)行示例時

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps

我們開始在日志文件中立即看到GC的影響，類似于以下內(nèi)容：

2015-06-04T13:34:16.119-0200: 1.723: [GC (Allocation Failure) [PSYoungGen: 114016K->73191K(234496K)] 421540K->421269K(745984K), 0.0858176 secs] [Times: user=0.04 sys=0.06, real=0.09 secs] 2015-06-04T13:34:16.738-0200: 2.342: [GC (Allocation Failure) [PSYoungGen: 234462K->93677K(254976K)] 582540K->593275K(766464K), 0.2357086 secs] [Times: user=0.11 sys=0.14, real=0.24 secs] 2015-06-04T13:34:16.974-0200: 2.578: [Full GC (Ergonomics) [PSYoungGen: 93677K->70109K(254976K)] [ParOldGen: 499597K->511230K(761856K)] 593275K->581339K(1016832K), [Metaspace: 2936K->2936K(1056768K)], 0.0713174 secs] [Times: user=0.21 sys=0.02, real=0.07 secs]

根據(jù)日志中的信息，我們可以著眼于三個不同的目標(biāo)來改善情況

確保最壞情況下的GC暫停不超過預(yù)定閾值

確保停止應(yīng)用程序線程的總時間不超過預(yù)定閾值

降低基礎(chǔ)架構(gòu)成本，同時確保我們?nèi)匀豢梢詫?shí)現(xiàn)合理的延遲和/或吞吐量目標(biāo)。

為此，上面的代碼在三種不同的配置上運(yùn)行了10分鐘，導(dǎo)致下表總結(jié)了三種截然不同的結(jié)果：

堆 GC算法 有用的工作 最長的停頓

-Xmx12g	-XX：+ UseConcMarkSweepGC	89.8％	560毫秒
-Xmx12g	-XX：+ UseParallelGC	91.5％	1,104毫秒
-Xmx8g	-XX：+ UseConcMarkSweepGC	66.3％	1,610毫秒

實(shí)驗(yàn)使用不同的GC算法和不同的堆大小運(yùn)行相同的代碼，以測量有關(guān)延遲和吞吐量的垃圾收集暫停的持續(xù)時間。 有關(guān)實(shí)驗(yàn)的詳細(xì)信息和結(jié)果的解釋，請參見《 垃圾收集手冊》 。 請查看手冊中的示例，了解有關(guān)配置的簡單更改如何使示例在延遲，容量吞吐量方面的表現(xiàn)完全不同。

請注意，為了使示例盡可能簡單，僅更改了有限數(shù)量的輸入?yún)?shù)，例如，實(shí)驗(yàn)未在不同數(shù)量的內(nèi)核或不同的堆布局上進(jìn)行測試。

翻譯自: https://www.javacodegeeks.com/2015/06/gc-tuning-in-practice.html

es 調(diào)整gc

總結(jié)

以上是生活随笔為你收集整理的es 调整gc_实际中进行GC调整的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。