Làm cách nào để theo dõi bộ nhớ JVM một cách thích hợp?


9

Tôi đang nghĩ về cách chúng ta thực hiện giám sát bộ nhớ JVM theo cách thấp trong môi trường sản xuất ngay cả trong giờ bận rộn.

Giả sử tôi có hai máy chủ ứng dụng tomcat đang sản xuất, cân bằng tải được thiết lập phía sau chúng. Nếu tôi có thể xem số liệu thống kê bộ nhớ jvm, tôi có thể yêu cầu cân bằng tải dừng gửi yêu cầu đến máy chủ sẽ gặp phải sự cố OOM. Làm điều này có ý nghĩa? Jconsole hoặc VisualVM ăn nhiều hiệu suất hơn không phải là lựa chọn của tôi.


Các khuôn khổ Java Simon có thể là một cái nhìn đáng.
khmarbaise

Câu trả lời:



1

Những người khác đã cung cấp các đề xuất về cách giám sát việc sử dụng bộ nhớ ...

Giả sử tôi có hai máy chủ ứng dụng tomcat đang sản xuất, cân bằng tải được thiết lập phía sau chúng. Nếu tôi có thể xem số liệu thống kê bộ nhớ jvm, tôi có thể yêu cầu cân bằng tải dừng gửi yêu cầu đến máy chủ sẽ gặp phải sự cố OOM. Làm điều này có ý nghĩa?

Sắp xếp Nhưng nó không nhất thiết là cách tốt nhất để giải quyết vấn đề của bạn.

Cho phép quay lại gốc rễ của vấn đề ... các OOME. Trong ngữ cảnh của Tomcat, OOME có thể được gây ra bởi một trong những điều sau đây:

  • rò rỉ bộ nhớ trong ứng dụng của bạn, (hoặc có thể là chính Tomcat),
  • cố gắng xử lý quá nhiều yêu cầu song song trên mỗi Tomcat, hoặc
  • yêu cầu cá nhân cần quá nhiều bộ nhớ trong quá trình xử lý.

Để giải quyết vấn đề của bạn, trước tiên bạn cần tìm hiểu xem điều gì đang xảy ra ... bởi vì giải pháp này khác nhau đối với mỗi vấn đề.

1) Để xem đây có phải là rò rỉ bộ nhớ hay không, bạn cần sử dụng công cụ phân tích bộ nhớ để kiểm tra các mẫu sử dụng bộ nhớ dài hạn. Điều này có thể sẽ hiển thị một mô hình răng cưa ... đó là bình thường. Những gì bạn cần tìm là mức độ đáy của "răng" có xu hướng tăng lên theo thời gian. Điều đó chỉ ra rằng một cái gì đó đang tạo ra rác không thể được thu thập; tức là rò rỉ bộ nhớ.

Nếu bạn bị rò rỉ bộ nhớ, thì giải pháp tốt nhất là tìm ra phần nào trong mã của bạn chịu trách nhiệm và khắc phục nó. Bất cứ điều gì khác ... bao gồm cả cân bằng tải ... là một giải pháp có dải băng và có thể dẫn đến các vấn đề tồi tệ hơn trên đường đua.

2) Đã loại bỏ rò rỉ bộ nhớ, bạn cần tìm hiểu xem vấn đề là bạn đang xử lý quá nhiều yêu cầu cùng một lúc. Tôi không chắc chắn về cách tốt nhất để làm điều đó, nhưng nếu đây là vấn đề (hoặc bạn nghi ngờ đó là) thì có một vài giải pháp khả thi:

  • Điều chỉnh cấu hình máy chủ Tomcat để giảm số lượng luồng công nhân.

  • Nếu các yêu cầu của bạn bị ràng buộc I / O, thì khả năng khác là xem xét hỗ trợ xử lý yêu cầu không đồng bộ có sẵn trong các phiên bản gần đây của thông số Servlet - xem http://docs.oracle.com/javaee/7/tutorial/doc/ servlets012.htm . Nhưng đó sẽ là công việc nhiều hơn.

3) Nếu vấn đề hóa ra là một số yêu cầu nhất định đang sử dụng quá nhiều bộ nhớ, thì bạn cần tìm ra cách phát hiện các yêu cầu đó trước khi xử lý và "giải quyết chúng". Cả việc phát hiện và xử lý các yêu cầu này có thể khó khăn ... và thật khó để tư vấn nếu không có chi tiết về ứng dụng của bạn. Nhưng một vài giải pháp thực dụng là:

  • Chuyển tiếp các yêu cầu dị thường đến một máy chủ khác với một đống lớn ... trong đó các OOME sẽ không can thiệp vào các yêu cầu "bình thường".

  • Tăng kích thước đống. Nếu bạn có đủ bộ nhớ vật lý, chạy với một đống lớn hơn thực sự có thể làm cho máy chủ Tomcat của bạn hiệu quả hơn ... cũng như tránh được OOME.


Tóm lại, thay vì cố gắng tải số dư để tránh OOME, tôi khuyên bạn nên tìm hiểu lý do tại sao bạn lại bị OOME ... và cố gắng giải quyết trực tiếp nguyên nhân của OOME.


0

Có lẽ jvmtop là giá trị cho bạn.

Nó cho bạn thấy một cách "giống như trên" trên các số liệu giám sát trên cơ sở mỗi jvm như mức tiêu thụ bộ nhớ, mức sử dụng cpu, số lượng luồng, v.v.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.