2013-04-18 39 views
5

Tôi đang giám sát hệ thống sản xuất với AppDynamics và chúng tôi chỉ có hệ thống thu thập dữ liệu chậm và gần như đóng băng. Ngay trước sự kiện này, AppDynamics đang hiển thị tất cả các hoạt động GC (nhỏ và lớn như nhau) flatline trong vài phút ... và sau đó trở lại với cuộc sống.HĐH có thể ngừng quá trình Java từ việc thu gom rác thải không?

Ngay cả trong thời gian tải cực thấp trên hệ thống, chúng tôi vẫn thấy các JVM của chúng tôi đang thực hiện một số hoạt động GC. Chúng tôi chưa bao giờ có nó hoàn toàn phẳng và thả xuống 0.

Ngoài ra - I/O mạng được căn hộ tại cùng một thời gian như đường viền GC/bộ nhớ.

Vì vậy, tôi hỏi: có thể một cái gì đó ở cấp hệ thống gây ra một JVM đóng băng, hoặc gây ra bộ sưu tập rác của nó để treo/đóng băng? Đây là trên một máy CentOS.

+0

_ "hệ thống chậm thu thập dữ liệu và gần như đóng băng" _ có rò rỉ bộ nhớ không? – phil

+0

Vâng, tôi biết nó nghe có vẻ như vậy, nhưng chúng tôi thấy số lượng bộ nhớ có sẵn co lại theo thời gian mà chúng tôi không có. Chắc chắn là một suy nghĩ tốt mặc dù. –

+0

Tôi đã nhìn thấy một cái gì đó như bạn mô tả trước đây bởi vì đối tượng tuyên bố đã không bao giờ đóng cửa, và sau một thời gian, đầy đống. Sử dụng VisualVM hoặc bất kỳ công cụ nào bạn muốn kiểm tra những gì sử dụng hầu hết bộ nhớ và xem nó có tiếp tục phát triển hay không. – phil

Trả lời

0

Hệ điều hành của bạn đã bật hoán đổi chưa.

Tôi đã nhận thấy các vấn đề HUGE với Java khi nó điền lên tất cả các ram trên một hệ điều hành với trao đổi kích hoạt - nó sẽ thực sự devistate hệ thống cửa sổ, effictevly khóa chúng và gây ra một khởi động lại.

Lý thuyết của tôi là thế này:

  • Các ram OS được gần đầy đủ.
  • Hệ điều hành yêu cầu bộ nhớ trở lại từ Java.
  • Điều này kích hoạt Java thành một GC đầy đủ để cố gắng giải phóng bộ nhớ.
  • GC đầy đủ chạm gần như mọi phần của bộ nhớ máy ảo, ngay cả các mục đã được hoán đổi.
  • Hệ thống cố gắng trao đổi dữ liệu trở lại bộ nhớ cho máy ảo (trên hệ thống đã hết ram)
  • Điều này giúp cho việc trượt tuyết.

Lúc đầu, nó không ảnh hưởng nhiều đến hệ thống, nhưng nếu bạn cố gắng khởi chạy ứng dụng muốn bộ nhớ mất nhiều thời gian và hệ thống của bạn sẽ giảm xuống.

Nhiều máy ảo lớn có thể làm điều này tồi tệ hơn, tôi chạy 3 hoặc 4 máy tính lớn và hệ thống của tôi hiện đang bị sieze khi tôi sử dụng hơn 60-70% RAM.

Đây là phỏng đoán nhưng nó mô tả hành vi mà tôi đã thấy sau nhiều ngày thử nghiệm.

Hiệu ứng là tất cả trao đổi có vẻ như "Ngăn" gc. Chính xác hơn, hệ điều hành đang chi tiêu hầu hết thời gian hoán đổi GC, làm cho nó trông giống như nó đang treo không làm gì trong GC.

Sửa lỗi - đặt -Xmx thành giá trị thấp hơn, thả nó cho đến khi bạn cho phép đủ chỗ để tránh hoán đổi. Điều này luôn khắc phục được sự cố của tôi, nếu nó không khắc phục được sự cố của bạn thì tôi sai về nguyên nhân gây ra sự cố của bạn :)

+0

Làm thế nào chính xác một hệ điều hành có thể yêu cầu bộ nhớ trở lại từ một quá trình? – user93353

+0

Tôi tin rằng hệ điều hành có thể báo hiệu điều kiện bộ nhớ thấp, nhưng tôi không thể tìm thấy tham chiếu.Tôi có thể sai nhưng hiệu quả là như mô tả - hệ thống xay dừng sau khi nó hết ram bất kể có bao nhiêu trao đổi có sẵn nếu một ứng dụng JAVA chiếm phần lớn ram. Tôi đã thấy điều này trong Linux nhưng nó được phát âm nhiều hơn trên các cửa sổ. Khi tôi đã cài đặt -Xmx sai, tôi phải khởi động lại máy khi nó đạt đến giới hạn ram. Ngoài ra GC dường như dừng lại trong thời gian này bởi vì hệ điều hành là chi tiêu tất cả thời gian của nó trao đổi (đó là như TicketMonster mô tả.) –

+0

Điều gì về tín hiệu này? http://msdn.microsoft.com/en-us/library/windows/desktop/aa366541(v=vs.85).aspx Nếu Java đáp ứng điều này, nó sẽ giải thích hành vi như tôi đã mô tả. –

1

Thật khó để tìm ra nguyên nhân chính xác của sự cố mà không có thêm thông tin.

Nhưng tôi có thể trả lời câu hỏi của bạn:
Hệ điều hành có thể chặn thu gom rác không?
Rất ít khả năng hệ điều hành của bạn chặn bộ thu gom luồng rác và cho phép các chủ đề khác chạy. Bạn không nên điều tra theo cách đó.

Hệ điều hành có thể chặn JVM không?
Có thể perflecty có thể và nó làm điều đó rất nhiều, nhưng quá nhanh so với bạn nghĩ rằng tất cả các quá trình đều chạy cùng một lúc.
jvm là một quá trình giống nhau và dưới sự kiểm soát của hệ điều hành. Bạn phải kiểm tra cpu được ứng dụng sử dụng khi nó treo (với giám sát trên máy chủ không có trong jvm). Nếu nó là rất thấp sau đó tôi nhìn thấy 2 nguyên nhân (nhưng có nhiều hơn nữa):

  • Máy chủ của bạn không có đủ bộ nhớ RAM và được trao đổi (RAM < -> đĩa), quá trình trở nên vô cùng chậm. Trong trường hợp này cpu sẽ cao trên máy chủ nhưng thấp cho jvm
  • Một quy trình hoặc máy chủ khác lấy tài nguyên và ứng dụng hoặc máy chủ của bạn không nhận được gì. Kiểm tra mức ưu tiên trên CentO.
0

Về lý thuyết, CÓ, có thể. Nhưng nó thực hành, nó không bao giờ nên.

Trong hầu hết các máy ảo Java, các luồng ứng dụng không phải là chủ đề duy nhất đang chạy. Ngoài các chủ đề ứng dụng, có các chủ đề biên dịch, các trình hoàn thiện, các chủ đề thu gom rác và một số chủ đề khác. Các quyết định lập kế hoạch phân bổ lõi CPU cho các luồng này và các luồng khác từ các chương trình khác đang chạy trên máy dựa trên nhiều tham số (ưu tiên luồng, thời gian thực hiện cuối cùng, v.v.). Vì vậy, trong thực tế không có thread trong hệ thống nên chờ đợi cho CPU phân bổ cho một thời gian dài bất hợp lý và hệ điều hành không nên chặn bất kỳ thread trong một khoảng thời gian không giới hạn.

Có hoạt động tối thiểu mà các chủ đề thu gom rác (và các chủ đề VM khác) cần thực hiện. Họ cần kiểm tra định kỳ để xem có cần thu gom rác hay không. Ngay cả khi các luồng ứng dụng đều bị treo, có thể có các luồng máy ảo khác, chẳng hạn như chuỗi trình biên dịch JIT hoặc chuỗi kết thúc, mà làm việc và, do đó, phân bổ các đối tượng và kích hoạt thu gom rác.Điều này đặc biệt đúng đối với JVM meta-tròn thực hiện các luồng VM trong Java và không phải trong C/C++;

Hơn nữa, JVM hiện đại nhất sử dụng bộ gom rác thế hệ (Bộ thu gom rác phân vùng heap thành các không gian riêng biệt và đặt đối tượng với các độ tuổi khác nhau trong các phần khác nhau của heap) Điều này có nghĩa là các đối tượng ngày càng già hơn được chuyển đến các không gian cũ khác. Do đó, ngay cả khi không cần thu thập đồ vật, một bộ thu gom rác thế hệ có thể di chuyển các vật thể từ không gian này sang không gian khác.

Tất nhiên, chi tiết của từng bộ thu gom rác khác nhau từ JVM đến JVM. Để đưa thêm muối vào vết thương, một số JVM hỗ trợ nhiều loại thu gom rác. Nhưng nhìn thấy một hoạt động thu gom rác thải tối thiểu trong một ứng dụng nhàn rỗi là không có gì ngạc nhiên.

Các vấn đề liên quan