Vì Java 7 sẽ sử dụng bộ sưu tập rác G1 mới theo mặc định, liệu Java sẽ có thể xử lý một thứ tự đống lớn hơn mà không có thời gian tạm dừng GC được cho là "tàn phá"? Đã có ai thực sự triển khai G1 trong sản xuất chưa, kinh nghiệm của bạn là gì?
Công bằng mà nói, lần duy nhất tôi thấy các khoảng dừng GC thực sự dài là trên các đống rất lớn, nhiều hơn một máy trạm sẽ có. Để làm rõ câu hỏi của tôi; G1 sẽ mở cổng vào đống hàng trăm GB? Lao?
Câu trả lời:
Có vẻ như quan điểm của G1 là có thời gian tạm dừng nhỏ hơn, thậm chí đến mức nó có khả năng chỉ định mục tiêu thời gian tạm dừng tối đa.
Thu gom rác không chỉ là một thỏa thuận đơn giản "Này, đã đầy rồi, hãy di chuyển mọi thứ cùng một lúc và bắt đầu lại" nữa - đó là hệ thống phân luồng nền, đa cấp, phức tạp đến kinh ngạc. Nó có thể thực hiện phần lớn công việc bảo trì ở chế độ nền mà không hề tạm dừng và nó cũng sử dụng kiến thức về các mẫu dự kiến của hệ thống trong thời gian chạy để trợ giúp - như giả sử hầu hết các đối tượng chết ngay sau khi được tạo, v.v.
Tôi có thể nói rằng thời gian tạm dừng của GC sẽ tiếp tục được cải thiện, không xấu đi, với các bản phát hành trong tương lai.
BIÊN TẬP:
Khi đọc lại, tôi chợt nhận ra rằng tôi sử dụng Java hàng ngày - Eclipse, Azureus và các ứng dụng mà tôi phát triển, và đã lâu rồi kể từ khi tôi thấy tạm dừng. Không phải là một khoảng dừng đáng kể, nhưng ý tôi là bất kỳ khoảng dừng nào.
Tôi đã thấy tạm dừng khi nhấp chuột phải vào windows explorer hoặc (thỉnh thoảng) khi tôi kết nối phần cứng USB nhất định, nhưng với Java --- thì không.
GC có còn là vấn đề với ai không?
Tôi đã thử nghiệm nó với một ứng dụng nặng: 60-70GB được phân bổ cho heap, với 20-50GB được sử dụng bất cứ lúc nào. Với những loại ứng dụng này, thật thiếu sót khi nói rằng quãng đường của bạn có thể thay đổi. Tôi đang chạy JDK 1.6_22 trên Linux. Các phiên bản nhỏ rất quan trọng-- trước khoảng 1.6_20, có một số lỗi trong G1 gây ra NullPointerExceptions ngẫu nhiên.
Tôi thấy rằng nó rất tốt trong việc duy trì mục tiêu tạm dừng mà bạn đưa ra hầu hết thời gian. Mặc định dường như tạm dừng 100ms (0,1 giây) và tôi đã bảo nó thực hiện một nửa điều đó (-XX: MaxGCPauseMillis = 50). Tuy nhiên, một khi bộ nhớ thực sự cạn kiệt, nó sẽ hoảng sợ và thực hiện việc thu gom rác toàn thế giới. Với 65GB, mất từ 30 giây đến 2 phút. (Số lượng CPU có thể không tạo ra sự khác biệt; nó có thể bị giới hạn bởi tốc độ bus.)
So với CMS (không phải là GC máy chủ mặc định, nhưng nó phải dành cho máy chủ web và các ứng dụng thời gian thực khác), các lần tạm dừng điển hình dễ dự đoán hơn nhiều và có thể được thực hiện ngắn hơn nhiều. Cho đến nay, tôi đang gặp may mắn hơn với CMS vì những lần tạm dừng rất lớn, nhưng điều đó có thể là ngẫu nhiên; Tôi chỉ nhìn thấy chúng một vài lần sau mỗi 24 giờ. Tôi không chắc cái nào sẽ phù hợp hơn trong môi trường sản xuất của tôi vào lúc này, nhưng có lẽ là G1. Nếu Oracle tiếp tục điều chỉnh nó, tôi nghi ngờ G1 cuối cùng sẽ là người chiến thắng rõ ràng.
Nếu bạn không gặp sự cố với các trình thu gom rác hiện có, không có lý do gì để xem xét G1 ngay bây giờ. Nếu bạn đang chạy một ứng dụng có độ trễ thấp, chẳng hạn như ứng dụng GUI, G1 có lẽ là lựa chọn phù hợp, với MaxGCPauseMillis được đặt thực sự thấp. Nếu bạn đang chạy một ứng dụng ở chế độ hàng loạt, G1 sẽ không mua cho bạn bất cứ thứ gì.
Mặc dù tôi chưa thử nghiệm G1 trong quá trình sản xuất, tôi nghĩ rằng tôi sẽ nhận xét rằng GC đã có vấn đề đối với các trường hợp không có đống "khổng lồ". Cụ thể, các dịch vụ chỉ có 2 hoặc 4 hợp đồng biểu diễn có thể bị ảnh hưởng nghiêm trọng bởi GC. GC thế hệ trẻ thường không có vấn đề gì vì chúng kết thúc bằng mili giây một chữ số (hoặc nhiều nhất là hai chữ số). Nhưng các bộ sưu tập thế hệ cũ gặp nhiều vấn đề hơn vì chúng mất nhiều giây với kích thước thế hệ cũ từ 1 gig trở lên.
Bây giờ: về lý thuyết, CMS có thể giúp ích rất nhiều ở đó, vì nó có thể chạy hầu hết các hoạt động đồng thời. Tuy nhiên, theo thời gian sẽ có những trường hợp không thể làm được điều này và đành phải lùi bước để "đình giới". Và khi điều đó xảy ra (chẳng hạn như sau 1 giờ - không thường xuyên, nhưng vẫn quá thường xuyên), hãy giữ vững chiếc mũ của bạn. Có thể mất một phút hoặc hơn. Điều này đặc biệt có vấn đề đối với các dịch vụ cố gắng hạn chế độ trễ tối đa; thay vì mất 25 mili giây để phân phát một yêu cầu thì giờ đây nó mất mười giây trở lên. Để gây thêm tổn thương cho việc xúc phạm khách hàng, sau đó khách hàng thường sẽ hết thời gian yêu cầu và thử lại, dẫn đến các vấn đề khác (còn gọi là "cơn bão shit").
Đây là một trong những lĩnh vực mà G1 hy vọng sẽ giúp được rất nhiều. Tôi đã làm việc cho một công ty lớn cung cấp dịch vụ đám mây để lưu trữ và gửi tin nhắn; và chúng tôi không thể sử dụng CMS vì mặc dù phần lớn thời gian nó hoạt động tốt hơn các giống song song, nhưng nó có những sự cố này. Vì vậy, trong khoảng một giờ mọi thứ rất tốt đẹp; và sau đó mọi thứ xảy ra với người hâm mộ ... và bởi vì dịch vụ dựa trên các cụm, khi một nút gặp sự cố, các nút khác thường theo sau (vì thời gian chờ do GC gây ra dẫn đến các nút khác tin rằng nút đã bị lỗi, dẫn đến việc định tuyến lại).
Tôi không nghĩ GC là vấn đề quá lớn đối với các ứng dụng và có lẽ ngay cả các dịch vụ không phân cụm cũng ít bị ảnh hưởng hơn. Nhưng ngày càng có nhiều hệ thống được phân cụm (đặc biệt là nhờ kho dữ liệu NoSQL) và kích thước heap ngày càng tăng. OldGen GC có liên quan siêu tuyến tính với kích thước heap (có nghĩa là tăng gấp đôi kích thước heap nhiều hơn gấp đôi thời gian GC, giả sử kích thước của tập dữ liệu trực tiếp cũng tăng gấp đôi).
CTO của Azul, Gil Tene, có một cái nhìn tổng quan tốt đẹp về các vấn đề liên quan đến Thu gom rác và đánh giá các giải pháp khác nhau trong bản trình bày Hiểu biết về Bộ sưu tập rác trong Java và những gì bạn có thể làm với nó và có thêm chi tiết trong bài viết này: http: // www.infoq.com/articles/azul_gc_in_detail .
Azul's C4 Garbage Collector trong Zing JVM của chúng tôi vừa song song vừa đồng thời và sử dụng cùng một cơ chế GC cho cả thế hệ mới và cũ, hoạt động đồng thời và thu gọn trong cả hai trường hợp. Quan trọng nhất, C4 không có điểm dừng của thế giới. Tất cả quá trình nén được thực hiện đồng thời với ứng dụng đang chạy. Chúng tôi có những khách hàng đang chạy rất lớn (hàng trăm GByte) với trường hợp xấu hơn thời gian tạm dừng GC là <10 msec và tùy thuộc vào ứng dụng, thời gian thường ít hơn 1-2 msec.
Vấn đề với CMS và G1 là tại một thời điểm nào đó bộ nhớ heap của Java phải được nén lại, và cả hai trình thu gom rác đó đều dừng-the-world / STW (tức là tạm dừng ứng dụng) để thực hiện nén. Vì vậy, mặc dù CMS và G1 có thể loại bỏ các tạm dừng STW, nhưng chúng không loại bỏ chúng. Tuy nhiên, C4 của Azul loại bỏ hoàn toàn các lệnh tạm dừng STW và đó là lý do tại sao Zing có mức tạm dừng GC thấp như vậy ngay cả đối với các kích thước heap khổng lồ.
Và để sửa lại câu trả lời trước đó, Zing không yêu cầu bất kỳ thay đổi nào đối với Hệ điều hành. Nó chạy giống như bất kỳ JVM nào khác trên các bản phân phối Linux chưa được sửa đổi.
Chúng tôi đã sử dụng G1GC, từ gần hai năm. Nó hoạt động rất tốt trong hệ thống xử lý giao dịch quan trọng trong sứ mệnh của chúng tôi và Nó được chứng minh là một hỗ trợ tuyệt vời với thông lượng cao, số lần tạm dừng thấp, đồng thời và quản lý bộ nhớ nặng được tối ưu hóa.
Chúng tôi đang sử dụng các cài đặt JVM sau:
-server -Xms512m -Xmx3076m -XX:NewRatio=50 -XX:+HeapDumpOnOutOfMemoryError -XX:+UseG1GC -XX:+AggressiveOpts -XX:+UnlockExperimentalVMOptions -XX:MaxGCPauseMillis=400 -XX:GCPauseIntervalMillis=8000 -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTimeĐã cập nhật
-d64 -server -Xss4m -Xms1024m -Xmx4096m -XX:NewRatio=50 -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:+HeapDumpOnOutOfMemoryError -XX:-DisableExplicitGC -XX:+AggressiveOpts -Xnoclassgc -XX:+UseNUMA -XX:+UseFastAccessorMethods -XX:ReservedCodeCacheSize=48m -XX:+UseStringCache -XX:+UseStringDeduplication -XX:MaxGCPauseMillis=400 -XX:GCPauseIntervalMillis=8000Bộ sưu tập G1 giảm tác động của các bộ sưu tập đầy đủ. Nếu bạn có một ứng dụng mà bạn đã giảm nhu cầu về các bộ sưu tập đầy đủ, thì bộ sưu tập Đồng thời quét bản đồ cũng tốt như vậy và theo kinh nghiệm của tôi, thời gian thu thập nhỏ hơn.
Có vẻ như G1 bắt đầu từ JDK7u4 cuối cùng cũng được hỗ trợ chính thức, hãy xem RN cho JDK7u4 http://www.oracle.com/technetwork/java/javase/7u4-relnotes-1575007.html .
Từ thử nghiệm của chúng tôi vẫn cho các JVM lớn, CMS được điều chỉnh vẫn hoạt động tốt hơn G1 nhưng tôi đoán nó sẽ phát triển tốt hơn.
Gần đây tôi đã được chuyển đến từ
CMS đến G1GC với bộ xử lý 4 nhân 4G & 8 lõi trên máy chủ với JDK 1.7.45 .
(JDK 1.8.x G1GC được ưa thích hơn 1.7 nhưng do một số hạn chế, tôi phải sử dụng phiên bản 1.7.45)
Tôi đã định cấu hình các thông số chính bên dưới và giữ tất cả các thông số khác thành giá trị mặc định.
-XX:G1HeapRegionSize=n, XX:MaxGCPauseMillis=m, -XX:ParallelGCThreads=n,
-XX:ConcGCThreads=n apart from -Xms and -XmxNếu bạn muốn tinh chỉnh các thông số này, hãy xem bài viết này của oracle .
Các quan sát chính:
Nhưng tôi vẫn thấy vui vì thời gian tạm dừng của Max GC ít hơn so với CMS. Tôi đã đặt thời gian tạm dừng Max GC là 1,5 giây và giá trị này vẫn chưa bị vượt qua.
Câu hỏi SE liên quan:
CMS có thể dẫn đến hiệu suất bị giảm sút từ từ ngay cả khi bạn đang chạy nó mà không tích lũy các đối tượng có thời hạn sử dụng. Điều này là do phân mảnh bộ nhớ mà G1 được cho là tránh.
Huyền thoại về G1 chỉ có sẵn với hỗ trợ trả phí chỉ có vậy, một huyền thoại. Sun và bây giờ là Oracle đã làm rõ điều này trên trang JDK.
Tôi vừa triển khai Trình thu gom rác G1 trong dự án Bộ nhớ lớn bằng đất nung của chúng tôi. Trong khi làm việc trên các loại bộ thu khác nhau, G1 đã cho chúng tôi kết quả tốt nhất với thời gian phản hồi dưới 600ms.
Bạn có thể tìm thấy kết quả kiểm tra (tổng số 26) tại đây
Hy vọng nó giúp.
Gần đây tôi đã di chuyển một phần của Twicsy sang một máy chủ mới với RAM 128GB và quyết định sử dụng 1.7. Tôi đã bắt đầu sử dụng tất cả các cài đặt bộ nhớ tương tự như tôi đã sử dụng với 1.6 (tôi có một số trường hợp đang chạy làm nhiều việc khác nhau, bất cứ nơi nào từ 500mb bộ nhớ lên đến 15GB và bây giờ là một cái mới với 40GB) và điều đó không hoạt động tốt chút nào . 1.7 dường như sử dụng nhiều heap hơn 1.6 và tôi đã gặp phải rất nhiều vấn đề trong vài ngày đầu tiên. Tôi may mắn có nhiều RAM để làm việc và tăng RAM cho hầu hết các quy trình của mình, nhưng vẫn gặp một số vấn đề. MO bình thường của tôi là sử dụng kích thước heap tối thiểu rất nhỏ là 16m, ngay cả với heap tối đa là vài gigabyte, sau đó bật GC tăng dần. Điều này giữ cho việc tạm dừng ở mức tối thiểu. Tuy nhiên, điều đó hiện không hoạt động và tôi đã phải tăng kích thước tối thiểu lên khoảng những gì tôi dự kiến sẽ sử dụng trung bình trong đống, và điều đó đã diễn ra rất tốt. Tôi vẫn bật GC gia tăng, nhưng tôi sẽ thử mà không có. Bây giờ không có gì tạm dừng và mọi thứ dường như đang chạy rất nhanh. Vì vậy, tôi nghĩ đạo lý của câu chuyện là đừng mong đợi cài đặt bộ nhớ của bạn dịch hoàn hảo từ 1,6 sang 1,7.
G1 làm cho ứng dụng nhanh nhẹn hơn rất nhiều: độ trễ của ứng dụng sẽ tăng lên - ứng dụng có thể được đặt tên là "thời gian thực mềm". Điều này được thực hiện bằng cách thay thế hai loại chạy GC (loại nhỏ nhỏ và một loại lớn trên Tenured Gen) thành loại nhỏ có kích thước bằng nhau.
Để biết thêm chi tiết, hãy xem tại đây: http://geekroom.de/java/java-expertise-g1-fur-java-7/
Tôi đang làm việc với Java, cho Heap nhỏ và lớn, và câu hỏi về GC và Full GC xuất hiện hàng ngày, vì các ràng buộc có thể nghiêm ngặt hơn các ràng buộc khác: trong một số môi trường nhất định, 0,1 giây của GC hoặc Full GC, kill chỉ đơn giản là fonctionnalité, và có cấu hình và khả năng chi tiết là rất quan trọng (CMS, iCMS, các loại khác ... mục tiêu là ở đây để có thời gian phản hồi tốt nhất có thể với xử lý gần như thời gian thực (ở đây xử lý thời gian thực thường là 25 mili giây) Vì vậy, về cơ bản, mọi cải tiến trong GC ergonomy ans heuristique đều được hoan nghênh!
Tôi sử dụng G1GC trên Java 8 và cũng với Groovy (cũng là Java 8), và tôi đang thực hiện nhiều loại khối lượng công việc khác nhau và nói chung G1GC hoạt động như thế này:
Việc sử dụng bộ nhớ rất thấp, ví dụ: 100MB thay vì 500MB so với cài đặt Java mặc định
Thời gian phản hồi nhất quán và rất thấp
Hiệu suất giữa cài đặt mặc định và G1GC bị chậm lại 20% khi sử dụng G1GC trong trường hợp xấu nhất (không điều chỉnh, ứng dụng đơn luồng). Nó không nhiều khi xem xét thời gian phản hồi tốt và sử dụng bộ nhớ thấp.
Khi chạy từ Tomcat đa luồng, hiệu suất tổng thể tốt hơn 30% và sử dụng bộ nhớ thấp hơn nhiều cũng như thời gian phản hồi cũng thấp hơn nhiều.
Vì vậy, nhìn chung, khi sử dụng các khối lượng công việc thực sự khác nhau, G1GC là bộ sưu tập rất tốt cho Java 8 cho các ứng dụng đa luồng và ngay cả đối với một luồng cũng có một số lợi ích.
Bạn không nên sử dụng java8 w / G1GC để tính toán dấu chấm động với JVM giống như điểm phát sóng. Nó nguy hiểm cho tính toàn vẹn và độ chính xác của ứng dụng.
https://bugs.openjdk.java.net/browse/JDK-8148175
JDK-8165766
JDK-8186112