Trong trường hợp nào một bộ sưu tập rác java của thế hệ trẻ kéo dài?

Question

ngày hôm qua chúng tôi đã có đầu ra sau đây GC trong nhật ký máy chủ của chúng ta về một máy chủ ứng dụng JBoss:

51628.286: [GC 51628.288: [ParNew: 1843200K->204800K(1843200K), 21.3196040 secs] 
5177730K->3743415K(7987200K), 21.3217870 secs] 
[Times: user=1.38 sys=0.33, real=21.32 secs] 

Tôi hiểu đầu ra như thế này: thế hệ trẻ có kích thước 1843200K. Kích thước trước khi tạo ra là 1843200K, kích thước sau 204800K. Bộ sưu tập kéo dài 21,3 giây.

Thông thường các bộ sưu tập thế hệ trẻ của chúng tôi cuối cùng < 1 giây. Trong những trường hợp nào bộ sưu tập yg kéo dài quá lâu?

chúng tôi JVM params:

-server 
-verbose:gc 
-XX:+PrintGCTimeStamps 
-XX:+PrintGCDetails 
-XX:NewRatio=3 
-XX:+UseConcMarkSweepGC 
-XX:+UseParNewGC 
-XX:+UseCMSCompactAtFullCollection 
-XX:CMSInitiatingOccupancyFraction=60 
-XX:MaxPermSize=256m 
-Xss512k 
-Xms8000m 
-Xmx8000m 

java phiên bản:

java version "1.6.0_29" 
Java(TM) SE Runtime Environment (build 1.6.0_29-b11) 
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode) 

Cảm ơn, Marcel

Answer 1

Chúng tôi đã có một máy chủ tomcat trong đó có bộ sưu tập rác kéo dài ~ 2 phút. Cuối cùng, chúng tôi đã tìm ra lý do, chúng tôi đã phân bổ nhiều bộ nhớ hơn cho JVM thông qua -Xmx hơn là chúng tôi có bộ nhớ vật lý trên hệ thống. Điều này đã gây ra phân trang trong quá trình thu gom rác, giết chết nó.

Ngoài ra, chúng tôi có nhiều máy ảo đang chạy trên cùng một máy vật lý. Hãy chắc chắn rằng bạn đã không cấp phát bộ nhớ nhiều hơn cho tất cả các máy ảo hơn là bạn có bộ nhớ vật lý trên máy chủ.

Để biết thêm thông tin, xem Tuning the Memory Management System, section Setting the Heap Size (tôi nhấn mạnh):

lệnh tùy chọn dòng: -Xms: -Xmx:

Kích thước đống có ảnh hưởng đến tốc độ phân bổ, thu gom rác thải tần số và thời gian thu gom rác thải. Một đống nhỏ sẽ trở thành đầy đủ một cách nhanh chóng và phải được thu gom rác thường xuyên hơn. Nó cũng dễ bị phân mảnh nhiều hơn, làm cho phân bổ đối tượng chậm hơn. Một đống lớn giới thiệu một chi phí nhỏ trong thời gian thu gom rác thải. Một đống mà lớn hơn bộ nhớ vật lý sẵn có trong hệ thống phải là được phân trang ra đĩa, dẫn đến thời gian truy cập dài hoặc thậm chí ứng dụng bị đóng băng, đặc biệt là khi thu gom rác.

Answer 2

Tôi tin rằng đó là đếm thời gian đồng hồ treo tường, vì vậy nếu các quá trình khác làm gián đoạn GC và chạy trong một thời gian thì sẽ bị báo cáo sai.

Không có gì trong thế hệ trẻ khiến bộ sưu tập mất nhiều thời gian - chi phí của GC tỷ lệ thuận với số mặt hàng có thể truy cập và số liệu của bạn cho thấy chỉ có một phần .

Quản lý hàng đợi tham chiếu và trình chạy finalizers có thể mất một lượng thời gian đáng kể nhưng không nên (??) được tính vào số đó.

http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html có các mẹo về điều chỉnh GC.

Answer 3

Bạn đang sử dụng bộ thu gom rác đồng thời (-XX:+UseConcMarkSweepGC), chạy trong một chuỗi riêng biệt.Từ đầu ra Times bạn đã đăng, có vẻ như bộ thu gom rác không chạy lâu. Tôi đoán rằng hệ thống của bạn không có đủ thời gian CPU để GC chạy, vì vậy mất 20 giây để GC có được thời gian CPU 1 s cần thiết. Khi sử dụng GC đồng thời, bạn nên đảm bảo rằng ứng dụng của bạn không ăn hết tất cả thời gian của CPU.

Nếu không có một thứ khác có thể xảy ra: Nếu bộ thu đồng thời không thể giải phóng đủ bộ nhớ và đạt đến một hàng rào nhất định, nó sẽ thực hiện một GC đầy đủ sẽ chặn tất cả các chuỗi khác và tốn nhiều thời gian. GC đầy đủ này có một đầu ra hơi khác nhau mặc dù (nói Full GC thay vì GC), vì vậy tôi đoán đây không phải là vấn đề của bạn ở đây.

Answer 4

Tôi chỉ cần stumbled trên một article nói rằng có phương pháp rất lớn có thể gây ra tạm dừng GC dài (Đó là phần cuối) Trích:

Khi một phương pháp được biên dịch, trình biên dịch tạo ra và lưu thông tin vào nơi đối tượng tài liệu tham khảo sống (Điều này giúp GC và được gọi là bản đồ oop) Các phương thức lớn hơn một kích thước nhất định sẽ không được JIT'ed trong điểm phát sóng. ... Nếu phương pháp này chưa được JIT'ed, GC phải tạo bản đồ oop trong GC. ... Các phương pháp lớn có nghĩa là thời gian diễn giải trừu tượng lớn để tạo ra các bản đồ oop. .... Nhân tiện, phương pháp khổng lồ này giống như 2500 dòng nên đó là thứ tôi gọi là rất lớn.

(Chữ in đậm được chèn)