G1 GC-非常长的终止时间
G1 GC有时会在终止阶段花费大量时间。如您所见，GC工作人员的平均终止时间为442.9，终止时间为327.3。这是处理大量消息的高性能低延迟应用程序。事件处理数据必须由young gc收集。通常事件处理不超过150毫秒。
HW:x24 Intel（R）Xeon（R）CPU E5-2620 v3@2.40GHz，32Gb内存，8Gb内存是免费的JVM选项：-server-XX:UseG1GC-XX:MaxGCPauseMillis=60-XX:ParallelGCThreads=24-Xmx12g-Xms12g-xs256K Linux 2.6.32-696.3。el6。x86_64 java版本“1.8.0_102”
通常G1会将新大小设置为7Gb，年轻GC暂停时间为50ms，终止时间仅为6ms，收集间隔为3秒。
如果应用程序产生了大量长寿对象，那么年轻暂停时间可能会增加，这也会导致年轻GC的大小减小。但在这种情况下，终止时间保持不变。我想知道为什么终止时间会如此缓慢地增加。
请注意此暂停的系统时间也很长。通常GC暂停的系统时间为0-10ms。对于这个，它是1秒。
2017-08-23T13:21:37.690-0400: 1509.022: [GC pause (G1 Evacuation Pause) (young), 0.4474119 secs]
[Parallel Time: 443.2 ms, GC Workers: 24]
[GC Worker Start (ms): Min: 1509022.9, Avg: 1509023.0, Max: 1509023.4, Diff: 0.4]
[Ext Root Scanning (ms): Min: 2.1, Avg: 22.5, Max: 90.4, Diff: 88.3, Sum: 539.7]
[Update RS (ms): Min: 0.0, Avg: 2.2, Max: 5.0, Diff: 5.0, Sum: 54.0]
[Processed Buffers: Min: 0, Avg: 24.7, Max: 67, Diff: 67, Sum: 592]
[Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.1, Diff: 0.1, Sum: 0.7]
[Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
[Object Copy (ms): Min: 26.1, Avg: 106.1, Max: 435.6, Diff: 409.6, Sum: 2545.3]
[Termination (ms): Min: 0.0, Avg: 312.0, Max: 327.3, Diff: 327.3, Sum: 7488.6]
[Termination Attempts: Min: 1, Avg: 1.5, Max: 4, Diff: 3, Sum: 36]
[GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.1, Diff: 0.0, Sum: 0.6]
[GC Worker Total (ms): Min: 442.5, Avg: 442.9, Max: 443.0, Diff: 0.5, Sum: 10628.9]
[GC Worker End (ms): Min: 1509465.9, Avg: 1509465.9, Max: 1509465.9, Diff: 0.1]
[Code Root Fixup: 0.4 ms]
[Code Root Purge: 0.0 ms]
[Clear CT: 0.3 ms]
[Other: 3.6 ms]
[Choose CSet: 0.0 ms]
[Ref Proc: 1.5 ms]
[Ref Enq: 0.0 ms]
[Redirty Cards: 0.4 ms]
[Humongous Register: 0.2 ms]
[Humongous Reclaim: 0.1 ms]
[Free CSet: 0.3 ms]
[Eden: 476.0M(476.0M)->0.0B(556.0M) Survivors: 136.0M->56.0M Heap: 4480.6M(12.0G)->4016.3M(12.0G)]
[Times: user=4.23 sys=1.08, real=0.45 secs]
共有1个答案
我有个建议。有时，当系统上运行其他进程时，它们会与Java GC工作人员发生冲突。
[对象复制（ms）：Min：26.1，Avg：106.1，Max：435.6，Diff：409.6，Sum：2545.3][Ext Root Scanning（ms）：Min：2.1，Avg：22.5，Max：90.4，Diff：88.3，Sum：539.7]
从上面的日志来看，GC工作人员的工作量似乎不成比例。这意味着大多数GC线程完成得很早，其中一些线程仍在工作。当这种情况发生时，完成的线程试图从其他线程窃取工作。这反映在终止时间上。因此，终止时间不是原因，而是副作用。
[终止（毫秒）：最小值：0.0，平均值：312.0，最大值：327.3，差异：327.3，总和：7488.6]
您有一台24核机器和24个GC工作线程。如果有其他进程或系统活动需要CPU资源，那么一些GC工作人员很可能会因为争用而被安排得很晚。
尝试将线程数减少到18并尝试一下是值得的。
您还可以增加gc日志级别，当您这样做时，它会打印每个线程的开始时间。这有助于调试应用程序。
-
不能做颤振运行。颤振医生可以做什么？（颤振版本2.8.1） 执行失败org.gradle.cache.internal.AsyncCacheAccessDecoratedCache$2@7c56f8f1.java.lang.OutOfMemoryError：Java堆空间
-
本文向大家介绍什么是PowerShell中的终止和非终止错误？，包括了什么是PowerShell中的终止和非终止错误？的使用技巧和注意事项，需要的朋友参考一下 Powershell执行脚本或命令时会生成两种类型的错误。终止错误和非终止错误。 终止错误-该错误是由您创建的脚本，函数或命令生成的，并且会停止或停止脚本的执行，从而导致下一行中的命令无法执行。要处理此错误，需要适当的机制，否则将显示错误消
-
问题内容： 我正在使用SQL Server 2008及其管理工作室。我执行了一个查询，该查询产生许多行。我试图通过红色的“取消”按钮将其取消，但在过去的10分钟内仍未停止。通常会在3分钟内停止。 原因可能是什么？如何立即停止？ 问题答案： 可能是什么原因 只要您的注意力可以到达服务器并得到处理，查询就会立即取消。查询必须处于可取消状态，几乎总是如此，除非您执行某些操作，例如从SQLCLR调用Web
-
我有一个压缩图像的任务，它在图像中使用了许多循环： 我在普通线程中运行此方法，如下所示： 或者在后台工作线程中运行 问题是：这种方法有时会出错，在接收无效输入时会导致无限循环。在这种情况下，它将永远运行，并损害CPU，即使当设备的屏幕关闭时，这会增加设备的温度（如果我使用工作线程，它还会阻止等待队列中的其他任务）。 我想我需要设置一个超时来终止长时间运行的任务。在正常Java线程中实现这一点的最佳
-
问题内容： 我正在构建一个访问angular / python RESTful API的Angular前端。 我正在使用AngularJS v1.2.16。 出于某种原因，在加载REST资源之前需要花费大量的时间，而大多数时间只是在等待。据我了解，“等待”正在衡量到第一个字节的时间- 我的所有服务都在本地运行（前端，API和数据库）。 鉴于所有服务都在本地运行，我不知如何调试它。有人在哪里找什么提
-
用j7u5，G1GC 对于给定的性能测试，可以预见，我的应用程序在运行5小时后会出现长时间的暂停。除了这个大的（也是唯一的），还有小的初始标记阶段。 任何建议来弄清楚这个长暂停发生了什么，以及如何调整它以避免影响延迟目标（百分位数98%, 99.999%)的如此长的暂停？