Lợi ích/nhược điểm khi chạy JVM 64 bit trên máy chủ Linux 64 bit?

Question

Chúng tôi chạy Sun Java 5 JVM 32 bit trên các máy chủ Linux 2.6 64 bit, nhưng dường như điều này hạn chế bộ nhớ tối đa của chúng tôi cho mỗi quá trình đến 2GB. Vì vậy, nó đã được đề xuất rằng chúng tôi nâng cấp lên JVM 64-bit để loại bỏ các hạn chế. Chúng tôi hiện đang chạy nhiều JVM (các phiên bản Tomcat) trên một máy chủ để ở dưới giới hạn 2 GB, nhưng chúng tôi muốn hợp nhất chúng với mục đích đơn giản hóa việc triển khai.

Nếu bạn đã thực hiện việc này, bạn có thể chia sẻ trải nghiệm của mình không? Bạn đang chạy JVM 64-bit trong sản xuất? Bạn có khuyên bạn nên ở lại Java 5, hoặc nó sẽ là ok để di chuyển đến cả hai Java 6 và 64 bit cùng một lúc? Chúng ta có nên mong đợi các vấn đề về hiệu suất, tốt hơn hay tệ hơn? Có bất kỳ khu vực cụ thể nào mà chúng ta nên tập trung vào thử nghiệm hồi quy của mình không?

Cảm ơn mọi mẹo!

Answer 1

Tại Kepler Trung tâm hoạt động khoa học, chúng tôi có khoảng 50 máy với 32-64G mỗi máy. Các JVMs heaps thường là 7-20G. Chúng tôi đang sử dụng Java 6. Hệ điều hành có hạt nhân Linux 2.6.

Khi chúng tôi di chuyển sang 64bit, tôi dự kiến ​​sẽ có một số vấn đề khi chạy JVM 64 bit Nhưng thực sự chưa có. Trong điều kiện bộ nhớ khó khăn hơn để gỡ lỗi vì các bãi chứa đống lớn hơn rất nhiều. Java Service Wrapper cần một số sửa đổi để hỗ trợ kích thước heap lớn hơn.

Có một số trang web trên web tuyên bố GC không quy mô tốt trong quá khứ 2G, nhưng tôi đã không thấy bất kỳ sự cố nào. Cuối cùng, chúng tôi đang thực hiện thông qua máy tính chuyên sâu tương đối chuyên sâu tương tác. Tôi chưa bao giờ nhìn vào sự khác biệt về độ trễ; tôi đoán là trường hợp xấu nhất GC độ trễ sẽ dài hơn với kích thước heap lớn hơn.

Answer 2

Chúng tôi sử dụng JVM 64 bit với số lượng khoảng 40   Gb. Trong ứng dụng của chúng tôi, rất nhiều dữ liệu được lưu trữ, dẫn đến một thế hệ "cũ" lớn. Các thiết lập thu gom rác mặc định không hoạt động tốt và cần một số điều chỉnh đau đớn trong sản xuất. Bài học: đảm bảo rằng bạn có cơ sở hạ tầng kiểm tra tải đầy đủ trước khi bạn mở rộng quy mô như thế này. Điều đó nói rằng, một khi chúng tôi nhận được các kinks làm việc ra, hiệu suất GC đã được tuyệt vời.

Answer 3

Tôi có thể xác nhận trải nghiệm của Sean. Chúng tôi đang chạy các dịch vụ web thuần Java, dịch vụ web chuyên sâu (tích hợp Jetty tự chế, với ngày nay hơn 1k chủ đề servlet, và> 6Gb dữ liệu đã tải trong bộ nhớ), và tất cả các ứng dụng của chúng tôi được chia tỷ lệ rất tốt với JVM 64 bit. di cư 2 năm trước. Tôi sẽ khuyên bạn nên sử dụng Sun JVM mới nhất, vì cải thiện đáng kể chi phí GC đã được thực hiện trong vài phiên bản gần đây nhất. Tôi cũng không gặp vấn đề gì với Wrapper của Tanukisoftware.

Answer 4

Bất kỳ mã JNI nào bạn đã viết cho rằng mã đang chạy trong 32 bit sẽ cần phải được kiểm tra lại. Đối với các vấn đề bạn có thể chạy vào porting c code từ 32 đến 64 bit, hãy xem liên kết này. Nó không phải là JNI cụ thể mà vẫn áp dụng. http://www.ibm.com/developerworks/library/l-port64.html

Answer 5

Nếu bạn sử dụng numactl - bạn có thể thấy kích thước của các ngân hàng bộ nhớ trong máy chủ của mình. Tôi đã tìm thấy GC không mở rộng tốt khi sử dụng nhiều ngân hàng bộ nhớ. Đây là một phần cứng nhiều hơn một vấn đề phần mềm IMHO nhưng nó có thể ảnh hưởng đến thời gian GC của bạn tất cả như nhau.

Answer 6

Sau khi di chuyển đến JDK6 64bits từ JDK5 32bits (máy chủ Windows), chúng tôi đã bị rò rỉ trong khối bộ nhớ "không gian gen". Sau khi chơi với các tham số JDK nó đã được giải quyết. Hy vọng bạn sẽ may mắn hơn chúng tôi.