Kết xuất chuỗi hiển thị trạng thái Runnable, nhưng nó bị treo trong một thời gian khá dài

Question

Chúng tôi đang đối mặt với một vấn đề bất thường trong ứng dụng của chúng tôi, trong một tháng qua ứng dụng của chúng tôi đã đạt đến trạng thái không thể phục hồi.

Bối cảnh: Ứng dụng của chúng tôi thực hiện truy vấn DB để tìm nạp một số thông tin và Cơ sở dữ liệu này được lưu trữ trên một nút riêng biệt.

Trường hợp có vấn đề: Khi kết xuất chuỗi được phân tích, chúng ta thấy tất cả các luồng nằm trong trạng thái runnable lấy dữ liệu từ cơ sở dữ liệu, nhưng nó không hoàn thành ngay cả sau 20 phút.

Đăng khởi động lại ứng dụng như mong đợi tất cả các chuỗi được khôi phục. Và việc sử dụng CPU cũng bình thường.

Dưới đây là thread bãi

ThreadPool: 2: 47" PRIO = 3 tid = 0x0000000007334000 nid = 0x5f Runnable [0xfffffd7fe9f54000] java.lang.Thread.State: Runnable tại oracle.jdbc. driver.T2CStatement.t2cParseExecuteDescribe (Native Method) tại oracle.jdbc.driver.T2CPreparedStatement.executeForDescribe (T2CPreparedStatement.java:518) tại oracle.jdbc.driver.T2CPreparedStatement.executeForRows (T2CPreparedStatement.java:764) tại ora

All threads in the same state. 

Câu hỏi:

1. những gì có thể là lý do cho tình trạng này?
2. cách khôi phục trong trường hợp này?

Answer 1

Có thể đang chờ dữ liệu mạng từ máy chủ cơ sở dữ liệu. Các luồng Java đang chờ (bị chặn) trên I/O được mô tả bởi JVM như đang ở trạng thái RUNNABLE mặc dù từ quan điểm của chương trình, chúng bị chặn.

Answer 2

Phương pháp gốc vẫn còn luôn là ở trạng thái RUNNABLE (ok, trừ khi bạn thay đổi trạng thái từ chính phương thức gốc, nhưng điều này không được tính).

Phương pháp này có thể bị chặn trên IO, bất kỳ sự kiện chờ đợi khác hoặc tác vụ mãnh liệt cpu dài ... hoặc vòng lặp vô tận. Bạn có thể tự chọn.

cách khôi phục trong trường hợp này?

thả kết nối từ oracle.

Answer 3

Như những người khác đã đề cập, các phương thức gốc luôn luôn chạy được, vì JVM không biết/quan tâm đến chúng.

Trình điều khiển Oracle ở phía máy khách không có thời gian chờ ổ cắm theo mặc định. Điều này có nghĩa là nếu bạn có vấn đề về mạng, ổ cắm mức thấp của máy khách có thể bị "kẹt" ở đó bao giờ hết, dẫn đến một hồ bơi kết nối maxxed. Bạn cũng có thể kiểm tra các thông tin về mạng đối với máy chủ Oracle để xem liệu nó có truyền dữ liệu hay không.

Khi sử dụng máy khách mỏng, bạn có thể đặt oracle.jdbc.ReadTimeout, nhưng tôi không biết làm thế nào để làm điều đó cho khách hàng dày (oci) bạn sử dụng, tôi không quen thuộc với nó.

Việc cần làm? Nghiên cứu cách bạn có thể chỉ định thời gian chờ đọc cho trình điều khiển ojdbc dày và xem các ngoại lệ liên quan đến thời gian chờ kết nối, điều này sẽ báo hiệu rõ ràng các sự cố mạng. Nếu bạn có thể thay đổi nguồn, bạn có thể kết thúc cuộc gọi và thử lại phiên khi bạn gặp SQLExceptions có liên quan đến thời gian chờ.

Để giải quyết nhanh sự cố, hãy chấm dứt kết nối trên máy chủ Oracle theo cách thủ công.

Kiểm tra giá trị phiên tranh chấp, có thể truy vấn chặn các phiên này. Nếu bạn tìm thấy một, bạn sẽ thấy đối tượng cơ sở dữ liệu nào gây ra sự cố.

Answer 4

Hệ thống hoặc JVM có bị treo cổ không? Nếu có thể định cấu hình và nếu có thể, hãy giảm số lượng chủ đề/kết nối song song.

Chủ đề chỉ đơn giản là lãng phí các chu kỳ CPU khi chờ IO. Có CPU của bạn là tiếc là giữ bận rộn bởi các chủ đề đang chờ phản hồi từ DB.

Answer 5

1. Mã của bạn có xử lý giao dịch thủ công không? Nếu sau đó, có thể một số mã không cam kết() sau khi thay đổi dữ liệu. Hoặc có thể ai đó chạy truy vấn sửa đổi dữ liệu trực tiếp thông qua PLSQL hoặc một cái gì đó và không cam kết, và dẫn tất cả các hoạt động đọc được treo.

2. Khi bạn gặp phải tình trạng "treo" và DB đã khôi phục từ trạng thái, bạn có kiểm tra dữ liệu nếu một số dữ liệu được khôi phục không? Yêu cầu này kể từ khi bạn nói "Nó đã được phục hồi ứng dụng bài khởi động lại." Nó xảy ra khi trình điều khiển JDBC thay đổi công cụ nhưng không cam kết, và thời gian chờ xảy ra ... hoạt động DB sẽ được khôi phục. (Có thể khác nhau dựa trên cấu hình mặc dù)