上图表现了部门trace快照。在这次垃圾网络进程中,三个P(总共12个P)专用于GC。你可以看到Goroutine 2450,1978和2696在这段时刻里正在举办Mark Assist的事变,而不是执行应用措施。在Mark的最后,只有一个P专用于GC并最终执行STW(标志终止)事变。
垃圾网络完成后,除了你看到Goroutines下面有许多玫瑰色的线条之外,应用措施险些规复尽力运行。

上图中那些玫瑰色线条代表Goroutine执行整理事变而非执行应用措施。这也是Goroutine试图分派新内存的时候。

上图图表现了Sweep进程中Goroutines stack trace的一部门。挪用runtime.mallocgc用于分派新内存。最终挪用runtime.(*mcache).nextFree 执行整理。一旦全部可以接纳的内存都接纳完毕,就不再对nextFree举办挪用。
方才描写的举动仅在垃圾网络启动并运行时产生。而GC百分比设置选项对付何时举办垃圾网络起着重要浸染。
GC百分比
运行时中有GC Percentage的设置选项,默认环境下为100。此值暗示在下一次垃圾网络必需启动之前可以分派几多新内存的比率。将GC百分比配置为100意味着,基于在垃圾网络完成后标志为勾当的堆内存量,下次垃圾网络前,堆内存行使可以增进100%。
举个例子,假设一个荟萃在行使中有2MB的堆内存。
留意:行使Go时,本文中堆内存的图表不代表真实环境。Go中的堆内存会碎片化。这些图只是表示图。

上图表现了最后一次垃圾完成后正在行使中的堆内存是2MB。因为GC百分比配置为100%,因此下一次收会议在在增进2 MB堆内存时启动。

上图表现增进2MB堆内存。这时触发一次垃圾网络。可觉得每次GC都天生GC trace,就可以查察到相干举措。
GC Trace
在运行任何Go应用措施时,可以通过行使情形变量GODEBUG和gctrace = 1选项天生GC trace。每次产生垃圾网络时,运行时城市将GC trace信息写入stderr。
- GODEBUG=gctrace=1 ./app
- gc 1405 @6.068s 11%: 0.058+1.2+0.083 ms clock, 0.70+2.5/1.5/0+0.99 ms cpu, 7->11->6 MB, 10 MB goal, 12 P
- gc 1406 @6.070s 11%: 0.051+1.8+0.076 ms clock, 0.61+2.0/2.5/0+0.91 ms cpu, 8->11->6 MB, 13 MB goal, 12 P
- gc 1407 @6.073s 11%: 0.052+1.8+0.20 ms clock, 0.62+1.5/2.2/0+2.4 ms cpu, 8->14->8 MB, 13 MB goal, 12 P
上面展示了怎样行使GODEBUG变量天生GC trace。同时表现了正在运行的Go应用措施天生的3条trace信息。
下面临GC trace中的每个值的寄义举办的解析。
- gc 1405 @6.068s 11%: 0.058+1.2+0.083 ms clock, 0.70+2.5/1.5/0+0.99 ms cpu, 7->11->6 MB, 10 MB goal, 12 P
-
- // General
- gc 1404 : The 1404 GC run since the program started
- @6.068s : Six seconds since the program started
- 11% : Eleven percent of the available CPU so far has been spent in GC
-
- // Wall-Clock
- 0.058ms : STW : Mark Start - Write Barrier on
- 1.2ms : Concurrent : Marking
- 0.083ms : STW : Mark Termination - Write Barrier off and clean up
-
- // CPU Time
- 0.70ms : STW : Mark Start
- 2.5ms : Concurrent : Mark - Assist Time (GC performed in line with allocation)
- 1.5ms : Concurrent : Mark - Background GC time
- 0ms : Concurrent : Mark - Idle GC time
- 0.99ms : STW : Mark Term
-
- // Memory
- 7MB : Heap memory in-use before the Marking started
- 11MB : Heap memory in-use after the Marking finished
- 6MB : Heap memory marked as live after the Marking finished
- 10MB : Collection goal for heap memory in-use after Marking finished
-
- // Threads
- 12P : Number of logical processors or threads used to run Goroutines
(编辑:湖南网)
【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!
|