1 Đối với kích thước heap khi bắt đầu GC, ở cuối GC và số heap sống từ gctrace = 1 là gì?

câu hỏi được tạo ra tại Wed, May 8, 2019 12:00 AM

Cài đặt GODEBUG=gctrace=1 khiến trình thu gom rác Go phát ra một dòng duy nhất thành lỗi tiêu chuẩn về thông tin nội bộ về mỗi vòng GC. Giả sử tôi có đầu ra này:

gc 1 @0.021s 0%: 0.15+0.37+0.25 ms clock, 3.0+0.19/0.39/0.60+5.0 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 2 @0.024s 0%: 0.097+0.94+0.16 ms clock, 0.29+0.21/1.3/0+0.49 ms cpu, 4->4->1 MB, 5 MB goal, 48 P
gc 3 @0.027s 1%: 0.10+0.43+0.17 ms clock, 0.60+0.48/1.5/0+1.0 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 4 @0.028s 1%: 0.18+0.41+0.28 ms clock, 0.18+0.69/2.0/0+0.28 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 5 @0.031s 1%: 0.078+0.35+0.29 ms clock, 1.1+0.26/2.0/0+4.4 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 6 @0.032s 1%: 0.11+0.50+0.32 ms clock, 0.22+0.99/2.3/0+0.64 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 7 @0.034s 1%: 0.18+0.39+0.27 ms clock, 0.18+0.56/2.2/0+0.27 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 8 @0.035s 2%: 0.12+0.40+0.27 ms clock, 0.12+0.63/2.2/0+0.27 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 9 @0.036s 2%: 0.13+0.41+0.26 ms clock, 0.13+0.52/2.2/0+0.26 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 10 @0.038s 2%: 0.099+0.51+0.20 ms clock, 0.19+0.56/1.9/0+0.40 ms cpu, 4->5->0 MB, 5 MB goal, 48 P
gc 11 @0.039s 2%: 0.10+0.46+0.20 ms clock, 0.10+0.23/1.3/0.005+0.20 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 12 @0.040s 2%: 0.066+0.46+0.24 ms clock, 0.93+0.40/1.7/0+3.4 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 13 @0.041s 2%: 0.099+0.30+0.20 ms clock, 0.099+0.60/1.7/0+0.20 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 14 @0.042s 2%: 0.095+0.45+0.24 ms clock, 0.38+0.58/2.0/0+0.98 ms cpu, 4->5->0 MB, 5 MB goal, 48 P
gc 15 @0.044s 2%: 0.095+0.45+0.21 ms clock, 1.0+0.78/1.9/0+2.3 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 16 @0.045s 3%: 0.10+0.45+0.23 ms clock, 0.10+0.70/2.1/0+0.23 ms cpu, 4->5->0 MB, 5 MB goal, 48 P
gc 17 @0.046s 3%: 0.088+0.40+0.17 ms clock, 0.088+0.45/1.9/0+0.17 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
.
.
.
.
gc 6789 @9.998s 12%: 0.17+0.91+0.24 ms clock, 0.85+1.8/5.0/0+1.2 ms cpu, 4->6->1 MB, 6 MB goal, 48 P
gc 6790 @10.000s 12%: 0.086+0.55+0.24 ms clock, 0.78+0.30/4.2/0.043+2.2 ms cpu, 4->5->1 MB, 6 MB goal, 48 P

Có một định nghĩa về các giá trị này trong tài liệu :

gc # @#s #%: #+#+# ms clock#+#/#/#+# ms cpu, #->#-># MB, # MB goal, #P 

where the fields are as follows:
gc #       the GC number, incremented at each GC
@#s        time in seconds since program start
#%         percentage of time spent in GC since program start
#+...+#    wall-clock/CPU times for the phases of the GC
#->#->#    MB heap size at GC start, at GC end, and live heap
# MB goal  goal heap size
# P        number of processors used

Điều tôi thực sự bối rối là #->#-># MB heap size at GC start, at GC end, and live heap.

  • Điều đó có đúng không, rằng tại mỗi vòng, GC sẽ giải phóng một lượng bộ nhớ (rác) không sử dụng cho HĐH và điều này phải giảm kích thước heap? Nếu có, thì tại sao một số giá trị của heap đang tăng? Ví dụ: 4- > 5- > 0. Chúng tôi có bộ nhớ 4 MB, bao gồm cả rác, trước khi bắt đầu GC. Sau đó, làm thế nào để có thể có được 5 MB bộ nhớ sau khi chúng tôi dọn sạch rác từ nó?

  • Giá trị thứ ba là kích thước heap trực tiếp. Sự khác biệt giữa kích thước heap thông thường là gì? Tôi cho rằng đó là đống rác.

  • Kích thước heap mục tiêu được tính như thế nào? Có đúng không, đó là một kích thước heap mà GC muốn đạt được sau khi dọn dẹp? Vậy thì tại sao giá trị này lớn hơn kích thước heap trước khi bắt đầu GC?

1
  1. Để làm rõ những gì được nói bên dưới, GC hoàn toàn không chịu trách nhiệm giải phóng bộ nhớ cho hệ điều hành (một trình goroutine riêng biệt xử lý, mặc dù nó báo cáo trong đầu ra gctrace nếu nó chạy). GC chỉ quan tâm đến việc quản lý bộ nhớ được phân bổ. Về mục tiêu, hãy đọc tài liệu cho biến env GOGC.
    2019-05-08 18: 25: 05Z
1 Câu trả lời                              1                         

GC dọn sạch một lượng rác mỗi lần vượt qua. Nó không nhất thiết phải phát hành nó cho HĐH (nếu nó nghĩ rằng nó sẽ phải yêu cầu nó một lần nữa); và nếu có, HĐH không nhất thiết phải lấy lại nó (cho đến khi có áp lực bộ nhớ từ một quy trình khác, HĐH có thể để bộ nhớ đó được phân bổ cho quy trình của bạn trong trường hợp cần lại).

Kích thước heap sống là số lượng heap được sử dụng tích cực, ít hơn bất kỳ đối tượng chết nào và không gian heap miễn phí sẵn sàng cho việc phân bổ trong tương lai. Kích thước heap mục tiêu là bao nhiêu bộ nhớ mà GC nghĩ cần có từ HĐH để xử lý phân bổ quy trình của bạn trên cơ sở liên tục mà không phải liên tục yêu cầu thêm bộ nhớ từ HĐH (tức là còn sống bao nhiêu + được phân bổ & GC chạy).

Mục tiêu của GC là dọn sạch các đối tượng chết trong heap, để duy trì đủ không gian heap miễn phí để xử lý hầu hết các phân bổ mà không phải yêu cầu thêm bộ nhớ từ HĐH (chậm), trong khi cũng không giữ bộ nhớ trống quá mức (để HĐH vẫn có thể phân bổ cho các tiến trình khác).

    
1
2019-05-08 16: 52: 10Z
nguồn đặt đây