Đối với ngữ cảnh của một hệ thống thời gian thực không được tạm dừng trong hơn 200 mili giây, chúng tôi đang tìm cách có cảnh báo trước trước khi có toàn bộ GC. Chúng tôi nhận ra rằng chúng tôi có thể không thể tránh được nó, nhưng chúng tôi muốn chuyển sang một nút khác trước khi hệ thống quầy hàng.Nhận cảnh báo trước khi đầy đủ GC
Chúng tôi đã có thể đưa ra một kế hoạch sẽ cung cấp cho chúng tôi cảnh báo trước, trước đầy đủ GC có thể khiến hệ thống ngừng trong vài giây (mà chúng tôi cần tránh).
Những gì chúng tôi có thể đưa ra dựa trên thống kê danh sách miễn phí CMS: -XX:PrintFLSStatistics=1. Điều này sẽ in số liệu thống kê danh sách miễn phí vào nhật ký GC sau mỗi chu kỳ GC, bao gồm GC trẻ, vì vậy thông tin có sẵn trong khoảng thời gian ngắn và sẽ xuất hiện thường xuyên hơn trong các khoảng thời gian phân bổ bộ nhớ cao. Nó có thể chi phí một chút về hiệu suất, nhưng giả định làm việc của chúng tôi là chúng ta có thể đủ khả năng đó.
Sản lượng vào nhật ký trông giống như vậy:
Statistics for BinaryTreeDictionary:
------------------------------------
Total Free Space: 382153298
Max Chunk Size: 382064598
Number of Blocks: 28
Av. Block Size: 13648332
Tree Height: 8
Đặc biệt, kích thước đoạn miễn phí tối đa là 382.064.598 lời. Với các từ 64 bit, số tiền này chỉ có thể dưới 2915MB. Con số này đã giảm rất chậm, với tốc độ khoảng 1MB mỗi giờ. Đó là sự hiểu biết của chúng tôi rằng miễn là kích thước chunk miễn phí tối đa lớn hơn thế hệ trẻ (giả sử không có phân bổ đối tượng humungous), mọi xúc tiến đối tượng nên thành công.
Gần đây, chúng tôi đã chạy thử nghiệm căng thẳng kéo dài vài ngày và đã thấy CMS có thể duy trì kích thước tối đa lên tới 94% tổng không gian vùng cũ. Kích thước tối đa miễn phí dường như giảm ở tốc độ dưới 1MB/giờ, điều này sẽ ổn - theo điều này, chúng tôi sẽ sớm không gặp GC đầy đủ và các máy chủ có thể sẽ ngừng hoạt động để bảo trì thêm thường xuyên hơn GC đầy đủ có thể xảy ra.
Trong thử nghiệm trước, tại thời điểm hệ thống kém hiệu quả bộ nhớ, chúng tôi có thể chạy hệ thống trong 10 giờ tốt. Trong giờ đầu tiên, kích thước chunk miễn phí tối đa đã giảm xuống còn 100MB, nơi nó ở lại trong hơn 8 giờ. Trong 40 phút cuối cùng của đợt chạy, kích thước đoạn tối đa miễn phí đã giảm ở tốc độ ổn định về 0, khi một GC đầy đủ xảy ra - điều này rất đáng khích lệ, vì khối lượng công việc đó dường như có thể nhận được 40 phút trước cảnh báo (khi kích thước đoạn bắt đầu giảm dần về 0).
Câu hỏi của tôi cho bạn: giả sử tất cả điều này phản ánh khối lượng công việc cao điểm kéo dài (khối lượng công việc tại bất kỳ điểm nào trong thời gian sản xuất sẽ chỉ thấp hơn), âm thanh này có giống như một phương pháp hợp lệ không? Bạn tin tưởng vào mức độ tin cậy nào mà chúng ta có thể đếm được trên số liệu thống kê kích thước đoạn miễn phí tối đa từ nhật ký GC?
Chúng tôi chắc chắn mở cho các đề xuất, nhưng yêu cầu chúng được giới hạn trong các giải pháp có sẵn trên HotSpot (Không có Azul cho chúng tôi, ít nhất là bây giờ). Ngoài ra, G1 không phải là giải pháp trừ khi chúng tôi có thể đưa ra một chỉ số tương tự sẽ cung cấp cho chúng tôi cảnh báo trước Full GC hoặc bất kỳ GC nào vượt quá SLA của chúng tôi (và đôi khi có thể xảy ra).
Có khả thi cho bạn để kiểm tra JRockit GC xác định không? http://docs.oracle.com/cd/E15289_01/doc.40/e15071/intro.htm#i1010645 – fglez
Chúng tôi biết về nó, cũng như các dịch vụ thời gian thực khác của IBM và Oracle. Điều quan trọng là chúng tôi phải có một số đảm bảo yếu hơn (hoặc thậm chí chỉ là chẩn đoán) cho phép chúng tôi triển khai trên HotSpot. – nadavwr
Bạn có cân nhắc việc buộc các GC đầy đủ định kỳ trên các nút xen kẽ không? Điều này sẽ cho phép hành vi dự đoán được nhiều hơn. CMS không thể dự đoán được trong dài hạn khi phân mảnh phát triển. – fglez