Tại sao bộ nhớ không bao giờ được phát hành trong ứng dụng JRuby Tomcat của tôi?

Question

Tôi có một ứng dụng JRuby on Rails đang chạy bên trong Tomcat (Warble). Nó sử dụng một cây cầu Java để kết nối với một máy chủ ứng dụng Progress (OpenEdge) ... Khi tôi theo dõi bộ nhớ, nó chỉ tiếp tục đi lên.

• Tomcat 7.0
• JRuby 1.6.7.2 (Ruby-1.9.2-p312)
• JVM 1.7.0.25
• Rails 3.2.7
• JRuby-rack 1.1.7
• warbler 1.3.6

Cách tốt nhất để đến đáy của vấn đề ở đây là gì? Tôi đoán nó có thể hoặc là các đối tượng JRuby không được làm sạch, hoặc một cái gì đó trong cây cầu Java hoặc Garbage collector mà không làm công việc của mình ...

Thậm chí nếu tôi để quá trình chạy trong nửa giờ , bộ nhớ không bị hỏng ...

• Có cách nào để biết đối tượng nào còn hoạt động không?
• Có công cụ miễn phí nào dễ sử dụng mà tôi có thể có thêm thông tin về ai đang sử dụng tất cả bộ nhớ không?

Bằng cách này, tôi đã có cấu hình máy chủ Tomcat để sử dụng nhiều bộ nhớ hơn, nhưng đó chỉ là trì hoãn một lỗi không gian đống ...

EDIT: Những gì tôi đang thực sự nhìn thấy là chỉ sử dụng Tomcat tất cả bộ nhớ mà nó có thể sử dụng tối đa (Maximum memory pool). Và nó không bao giờ phát hành nó. Có lẽ nó chỉ là hành vi bình thường ... Tôi đã thiết lập tối đa 256MB ví dụ và trong Task Manager, bộ nhớ chỉ ở mức 256MB.

EDIT:

Khi tạo một đống đổ và để thực phân tích nó với Eclipse Memory Analyzer này là báo cáo tôi nhận được. Tôi nghĩ đó là bình thường vì công cụ này có lẽ không mong đợi những câu chuyện toàn JRuby ...

vấn đề nghi ngờ 1

6,458 trường hợp của "org.jruby.RubyClass", nạp bởi "org.apache. catalina.loader.WebappClassLoader @ 0x700ec6988 "chiếm 56,969,616 (31,78%) byte.

Từ khóa org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988 org.jruby.RubyClass

vấn đề nghi ngờ 2

10,597 trường hợp của "org.jruby.internal.runtime.methods. DefaultMethod ", được tải bởi" org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988 "chiếm 22.182.112 (12,37%) byte.

Từ khóa org.jruby.internal.runtime.methods.DefaultMethod org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988

vấn đề nghi ngờ 3

3,144 trường hợp của "org.jruby.RubyModule", nạp bởi "org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988" chiếm 21.226.816 (11,84 %) byte.

Từ khóa org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988 org.jruby.RubyModule

vấn đề nghi ngờ 4

8,888 trường hợp của "org.jruby.MetaClass", nạp bởi " org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988 "chiếm 18,563,784 (10,35%) byte.

Từ khóa org.jruby.MetaClass org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988

Answer 1

này có mùi rất giống bộ nhớ bị rò rỉ. Không phải là một cảnh đẹp.

Nếu không có nhiều mã, trước tiên hãy kiểm tra bằng mắt, rằng bạn đang đóng các kết nối và luồng và tất cả các đối tượng có phương thức close. Nếu đây là vấn đề hiển thị gần đây, hãy xem mã sửa đổi lần cuối.

Điều khác tôi sẽ thử là kiểm tra mã với some tool.

Có thể viết một số kiểm tra để tăng tốc độ rò rỉ (như yêu cầu tạo), sau đó bạn có thể thử loại trừ mã khỏi ứng dụng, cho đến khi bạn tìm thấy khu vực đang gây rò rỉ.

Tôi không khuyên bạn nên kiểm tra các đối tượng trong bộ nhớ vì nó là một quá trình chậm và đau đớn.

Answer 2

Trước hết: 256M Không gian Heap không nhiều cho các ứng dụng Java - đặc biệt là một thùng chứa servlet/máy chủ ứng dụng đầy đủ có liên quan và (rất nhiều) thư viện.

Java thường không trao lại bộ nhớ cho hệ điều hành - khi được cấp phát bộ nhớ được coi là thuộc sở hữu của JVM. Tôi tin rằng có thể có một số triển khai về quản lý bộ nhớ để trao lại bộ nhớ, nhưng tôi chưa từng thấy chúng. Khuyến nghị điển hình của tôi trong môi trường sản xuất là phải có -Xmx bằng -Xm anyway (phân bổ tất cả bộ nhớ bạn muốn JVM có thể phân bổ ngay lập tức)

Heap Space là tín hiệu cho một trong hai (hoặc nhiều hơn)) điều kiện: a) Bạn có một ứng dụng bị rò rỉ bộ nhớ, b) bạn không phân bổ đủ cho nhu cầu ứng dụng.

Tăng phân bổ bộ nhớ cho JVM của bạn và giám sát việc sử dụng bộ nhớ và thu gom rác thải để loại trừ b) - nếu bạn có thể an toàn nói rằng ứng dụng của bạn có đủ bộ nhớ cho nhu cầu của nó, tìm kiếm a) và xác định nguyên nhân gốc của bộ nhớ bị rò rỉ. Bạn sẽ sử dụng profiler tốt nhất cho điều đó, nhưng với 256M bộ nhớ, có nhiều khả năng là bạn không có đủ bộ nhớ.