tải cao có thể khiến máy chủ bị treo và lỗi bị chặn trong hơn 120 giây không?

17

Hiện đang chạy một số máy chủ của VM và 'baremetal'. Java đang chạy ở mức cao - hơn 400% + nhiều lần. Ngẫu nhiên, máy chủ bị treo với lỗi trong bảng điều khiển "java - bị chặn trong hơn 120 giây" - kjournald, v.v.

Tôi không thể nhận được đầu ra dmesg vì một số lý do, lỗi này chỉ ghi vào bảng điều khiển mà tôi không có quyền truy cập do điều này được lưu trữ từ xa. do đó tôi không thể sao chép một dấu vết đầy đủ.

Tôi đã thay đổi môi trường này - ngay cả máy chủ vật lý và nó vẫn đang diễn ra.

Tôi đã thay đổi hung_task_timeout_secs thành 0 trong trường hợp đó là kết quả dương tính giả theo http://docs.redhat.com/docs/en-US/Red_Hat_ Entryprise_Linux / 6 / ml / Technical_Notes / depep.html .

Ngoài ra, mất cân bằng không được cài đặt, có lẽ nó sẽ giúp?

đây là Ubuntu 10.04 64 bit - cùng một vấn đề với máy chủ 2.6,38-15 và 2,6,36 mới nhất.

cpu hoặc các vấn đề bộ nhớ / không có trao đổi trái gây ra vấn đề này?

đây là thông báo trên bàn điều khiển:

[58Z?Z1.5?Z840] INFUI task java:21547 blocked for more than 120 seconds.
[58Z?Z1.5?Z986] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?Z06Z] INFUI task kjournald:190 blocked for more than 120 seconds.
[58Z841.5?Z336] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?Z600] INFUI task flush-202:0:709 blocked for more than 120 seconds.
[58Z841.5?Z90?] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?3413] INFUI task java:21547 blocked for more than 120 seconds.
[58Z841.5?368Z] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z961.5?ZZ36] INFUI task kjournald:60 blocked for more than 120 seconds.
[58Z961.5?Z6Z5] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z961.5?31ZZ] INFUI task flush-202:0:709 blocked for more than 120 seconds.
[58Z961.5?3393] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.

linux kernel

— Tee
nguồn

15

Vâng, nó có thể.

Điều này có nghĩa là khá rõ ràng: hạt nhân không thể lên lịch tác vụ trong 120 giây. Điều này biểu thị sự đói tài nguyên, thường là xung quanh việc truy cập đĩa.

irqbalancecó thể giúp đỡ, nhưng điều đó không có vẻ rõ ràng. Bạn có thể cung cấp cho chúng tôi xung quanh thông báo này dmesg, đặc biệt là dấu vết ngăn xếp theo sau nó không?

Hơn nữa, đây không phải là một dương tính giả. Điều này không nói rằng nhiệm vụ được treo mãi mãi , và tuyên bố là hoàn toàn chính xác. Điều đó không có nghĩa đó là vấn đề đối với bạn và bạn có thể quyết định bỏ qua nếu bạn không nhận thấy bất kỳ tác động nào của người dùng.

Điều này không thể được gây ra bởi:

một vấn đề CPU (hay đúng hơn, đó sẽ là một lỗi phần cứng không thể khắc phục được),
một vấn đề về bộ nhớ (rất có thể là lỗi phần cứng, nhưng sẽ không xảy ra nhiều lần; không phải là thiếu RAM như một quá trình oom-killed),
thiếu trao đổi ( oom-killermột lần nữa).

Để mở rộng, bạn có thể đổ lỗi cho việc thiếu bộ nhớ theo nghĩa là việc tước hệ thống bộ nhớ đệm dữ liệu trong RAM sẽ gây ra nhiều I / O hơn. Nhưng nó không đơn giản như "hết bộ nhớ".

— Hãng vận tải Pierre
nguồn

Không có gì được ghi vào / var / log / dmesg vì vậy tôi chỉ dán những gì Bảng điều khiển hiển thị .. khi điều này xuất hiện, hệ thống được treo 100%.

— Tee

Thông báo này đến từ kernel, nó sẽ xuất hiện dmesg(nếu nó được ghi lại gần đây) vì lệnh này in bộ đệm vòng ghi nhật ký kernel. Hy vọng rằng syslogthiết lập của bạn cũng sẽ đăng nhập nó ở đâu đó /var/log, nhưng tôi không thể biết nơi nào.

— Pierre Carrier

Thông báo sẽ KHÔNG xuất hiện /var/log/dmesg, nhưng có thể bật lên khi bạn chạy dmesglệnh. Tệp được tạo trong quá trình khởi động và thường chỉ ghi lại các thông báo kernel thời gian khởi động (cuối cùng sẽ cuộn ra khỏi bộ đệm vòng kernel. Bạn cũng có thể cài đặt / kích hoạt sysstatvà xem việc sử dụng tài nguyên như đã báo cáo ở đó. I / O / iowait, có khả năng liên quan đến trao đổi (sysstat sẽ giúp xác định điều này)

— Tiến sĩ Edward Morbius

@ Dr.EdwardMorbius Vậy làm cách nào để khắc phục điều này? Tôi đang gặp vấn đề lớn liên quan đến vấn đề này với máy chủ Zimbra của chúng tôi đang hoạt động rất tốt trong môi trường sản xuất cho đến gần đây.

— Bỏ qua

@Lopsided: Xin lỗi vì sự chậm trễ, tôi không ở đây thường xuyên. Tóm lại: bạn sẽ phải lập hồ sơ quy trình Java của bạn và tìm hiểu lý do tại sao nó bị treo. Thu gom rác là một lĩnh vực tôi đã có vấn đề (và thành công) trong việc điều chỉnh. Tra cứu ergodymics bộ sưu tập rác JVM và xem oracle.com/technetwork/java/javase/gc-tuning-6-140523.html Tôi thấy heap tăng lên rõ rệt.

— Bác sĩ Edward Morbius

6

sudo sysctl -w vm.dirty_ratio=10
sudo sysctl -w vm.dirty_background_ratio=5

Sau đó cam kết thay đổi với:

sudo sysctl -p

giải quyết nó cho tôi ....

— Nick
nguồn

6

Bạn nên giải thích những gì từng cài đặt làm.

— kasperd

6

Điều này đã khắc phục một vấn đề tương tự tôi gặp phải trong môi trường docker. Tôi tìm thấy một lời giải thích ở đây: blackmoreops.com/2014/09/22/ . "Theo mặc định, Linux sử dụng tới 40% bộ nhớ khả dụng cho bộ nhớ đệm hệ thống tệp. Sau khi đạt được dấu này, hệ thống tệp sẽ xóa tất cả dữ liệu chưa xử lý vào đĩa khiến tất cả các IO sau sẽ đồng bộ hóa. Để xóa dữ liệu này vào đĩa giới hạn thời gian là 120 giây theo mặc định. Trong trường hợp ở đây, hệ thống con IO không đủ nhanh để xóa dữ liệu mà ... "

— Peter M

2

Gần đây tôi đã gặp lỗi này trong một trong các cụm sản xuất của chúng tôi:

Ngày 11 tháng 11 14:56:41 xxx kernel: INFO: task xfsalloc / 3: 2393 bị chặn trong hơn 120 giây.

Ngày 11 tháng 11 14:56:41 Hạt nhân Xxxx: Không bị nhiễm bẩn 2.6.32-504.8.1.el6.x86_64 # 1

Ngày 11 tháng 11 14:56:41 xxx: "echo 0> / Proc / sys / kernel / hung_task_timeout_secs" vô hiệu hóa thông báo này.

..

Khi xác minh thêm các bản ghi sar Tìm thấy chờ đợi IO đã tăng lên trong cùng thời gian.

Và khi kiểm tra Phần cứng (Đĩa vật lý) đã thấy các lỗi trung bình và các lỗi SCSI khác đã ghi lại trên một Đĩa vật lý, do đó đã chặn các IO, do thiếu tài nguyên để phân bổ.

11/11/15 19:52:40: chấm dứt pRdm 607b8000 flags = 0 TimeOutC = 0 RetryC = 0 Yêu cầu c1173100 Trả lời 60e06040 iocStatus 0048 retryC 0 devId: 3 devFlags = f1482005

11/11/15 19:52:40: DM_ProcessDevWaitQueue: Nhiệm vụ mgmt trong tiến trình devId = x 11/11/15 19:52:40: DM_ProcessDevWaitQueue: Nhiệm vụ mgmt trong tiến trình devId = x

Vì vậy, điều này là do lỗi phần cứng, trong cụm của chúng tôi.

Vì vậy, sẽ rất tốt, nếu bạn có thể kiểm tra tệp lõi và nếu tiện ích ipmi ở đó, hãy kiểm tra lệnh ipmiutil / ipmitool sel elist để kiểm tra sự cố.

Trân trọng, VT

— Varun Thomas
nguồn

0

Bạn có thể truy cập vào giao diện giám sát của nhà cung cấp đám mây của mình và kiểm tra xem bạn có vượt quá IOps tối đa được chỉ định cho bộ nhớ của mình không, điều đó sẽ giải thích lý do tại sao phải mất nhiều thời gian để xóa dữ liệu bộ đệm.
IOps tối đa có sẵn trên trang thuộc tính lưu trữ của bạn.

— Emmanuel
nguồn