2010-05-25 24 views
12

tôi nhìn thấy các triệu chứng sau đây trong hồ sơ GC log của một ứng dụng với đồng thời thu Mark-Sweep:JVM CMS rác Thu vấn đề

4031.248: [CMS-concurrent-preclean-start] 
4031.250: [CMS-concurrent-preclean: 0.002/0.002 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
4031.250: [CMS-concurrent-abortable-preclean-start] 
CMS: abort preclean due to time 4036.346: [CMS-concurrent-abortable-preclean: 0.159/5.096 secs] [Times: user=0.00 sys=0.01, real=5.09 secs] 
4036.346: [GC[YG occupancy: 55964 K (118016 K)]4036.347: [Rescan (parallel) , 0.0641200 secs]4036.411: [weak refs processing, 0.0001300 secs]4036.411: [class unloading, 0.0041590 secs]4036.415: [scrub symbol & string tables, 0.0053220 secs] [1 CMS-remark: 16015K(393216K)] 71979K(511232K), 0.0746640 secs] [Times: user=0.08 sys=0.00, real=0.08 secs] 

Quá trình làm sạch trước tiếp tục hủy liên tục. Tôi đã thử điều chỉnh CMSMaxAbortablePrecleanTime thành 15 giây, từ mặc định là 5, nhưng điều đó không giúp được gì. Các tùy chọn JVM hiện tại là như sau ...

Djava.awt.headless=true 
-Xms512m 
-Xmx512m 
-Xmn128m 
-XX:MaxPermSize=128m 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:+UseParNewGC 
-XX:+UseConcMarkSweepGC 
-XX:BiasedLockingStartupDelay=0 
-XX:+DoEscapeAnalysis 
-XX:+UseBiasedLocking 
-XX:+EliminateLocks 
-XX:+CMSParallelRemarkEnabled 
-verbose:gc 
-XX:+PrintGCTimeStamps 
-XX:+PrintGCDetails 
-XX:+PrintHeapAtGC 
-Xloggc:gc.log 
-XX:+CMSClassUnloadingEnabled 
-XX:+CMSPermGenPrecleaningEnabled 
-XX:CMSInitiatingOccupancyFraction=50 
-XX:ReservedCodeCacheSize=64m 
-Dnetworkaddress.cache.ttl=30 
-Xss128k 

Dường như tiền đồng thời hủy bỏ không bao giờ có cơ hội để chạy. Tôi đọc qua https://blogs.oracle.com/jonthecollector/entry/did_you_know có đề xuất bật CMSScavengeBeforeRemark, nhưng tác dụng phụ của việc tạm dừng có vẻ không lý tưởng. Bất cứ ai có thể đưa ra bất kỳ đề nghị?

Ngoài ra tôi đã tự hỏi nếu có ai đã có một tài liệu tham khảo tốt cho grokking các bản ghi CMS GC, đặc biệt dòng này:

[1 CMS-remark: 16015K(393216K)] 71979K(511232K), 0.0746640 secs] 

Không rõ ràng về vùng những gì nhớ những con số này được đề cập đến. Sửa Tìm thấy một liên kết đến đây http://www.sun.com/bigadmin/content/submitted/cms_gc_logs.jsp

+0

Thẻ cms được sử dụng để tham chiếu đến hệ thống quản lý nội dung, không phải nhãn đồng thời và GC quét. Tôi sẽ loại bỏ nó. –

+0

Rất tiếc về điều đó, cảm ơn – jlintz

+0

Bắt đầu CMS ở mức 50% có vẻ thấp với tôi: -XX: CMSInitiatingOccupancyFraction = 50 Có thể tăng (hoặc sử dụng mặc định là 'antispam') sẽ hoạt động khác. Ngoài ra, nhật ký của tôi thường có ParNew chạy chúng trước, trong và sau CMS. ParNew có đang chạy không? –

Trả lời

3

[Times: user = 0.00 sys = 0,01, thực = 5,09 giây]

tôi sẽ cố gắng điều tra tại sao CMS-concurrent-abortable-preclean-start không nhận được không phải người sử dụng cũng không sys CPU thời gian trong 5 giây.

Đề nghị của tôi được bắt đầu từ một JVM CMS cờ khởi động 'sạch' như

-Djava.awt.headless=true 
-Xms512m 
-Xmx512m 
-Xmn128m 
-Xss128k 
-XX:MaxPermSize=128m 
-XX:+UseConcMarkSweepGC 
-XX:+HeapDumpOnOutOfMemoryError 
-Xloggc:gc.log 
-XX:+PrintGCTimeStamps 
-XX:+PrintGCDetails 
-XX:+PrintHeapAtGC 

sau đó kiểm tra nếu vấn đề tái tạo và giữ tinh chỉnh một tham số cùng một lúc.

3

Như ai đó đã đề cập, bước đầu tiên là tăng CMSInitiatingOccupancyFraction.

Bước thứ hai, tôi sẽ sử dụng cờ -XX:-PrintTenuringDistribution và đảm bảo rằng không có quảng bá sớm từ thế hệ trẻ đến thế hệ cũ. Điều này sẽ dẫn đến các tài liệu tham khảo cũ để trẻ có thể dẫn đến một giai đoạn preclean abortable dài hơn. Nếu có chương trình khuyến mãi sớm như vậy, hãy thử điều chỉnh tỷ lệ giữa các khoảng trống và các khoảng trống bên trái.

2

Có một lời giải thích tốt here về hiện tượng này:

Trích:

Vì vậy, khi tải của hệ thống là ánh sáng (có nghĩa là sẽ không có gc nhỏ), precleaning sẽ luôn hết thời gian và đầy đủ gc sẽ luôn luôn không thành công. cpu là chất thải.

Nó sẽ không thành công. Nó sẽ ít song song hơn (tức là ít hiệu quả hơn và sẽ có thời gian tạm dừng lâu hơn, cho công việc thấp hơn).

Vì vậy, tất cả trong tất cả: điều này có vẻ là hoạt động bình thường - luồng chỉ đợi một GC nhỏ xảy ra trong 5 giây, nhưng không có vấn đề lớn khi điều này không xảy ra: JVM chọn khác nhau (ít hiệu quả hơn) để tiếp tục với GC.