높은로드로 인해 서버가 정지되고 "120 초 이상 차단"오류가 발생할 수 있습니까?

현재 몇 개의 VM 및 '베어 메탈'서버가 실행 중입니다. Java는 때때로 400 % 이상에서 실행되고 있습니다. 콘솔 "java-120 초 이상 차단됨"-kjournald 등의 오류로 서버가 임의로 정지됩니다.

어떤 이유로 든이 오류는 콘솔에 기록하기 때문에 dmesg 출력을 얻을 수 없습니다. 이는 원격으로 호스팅되므로 액세스 할 수 없습니다. 따라서 전체 추적을 복사 할 수 없습니다.

나는 이것이 물리적 서버조차도있는 환경을 바꿨으며 여전히 일어나고 있습니다.

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/deployment.html에 따라 거짓 양성인 경우 hung_task_timeout_secs를 0으로 변경했습니다 .

또한 irqbalance가 설치되어 있지 않습니다. 아마도 도움이 되겠습니까?

이것은 최신 2.6.38-15 서버 및 2.6.36에서 우분투 10.04 64 비트와 동일한 문제입니다.

CPU 또는 메모리 문제 / 스왑이 남지 않아이 문제가 발생할 수 있습니까?

콘솔 메시지는 다음과 같습니다.

[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.

그렇습니다.

이것이 의미하는 바는 명백하다. 커널은 120 초 동안 작업을 예약 할 수 없었다. 이것은 종종 디스크 액세스와 관련된 리소스 부족을 나타냅니다.

irqbalance도움이 될 수 있지만 분명하게 들리지는 않습니다. 에서이 메시지의 주변 dmesg, 특히 그 뒤에 오는 스택 추적을 제공 할 수 있습니까?

더욱이 이것은 오 탐지 가 아닙니다 . 이것은 그 과제가 영원히 중단되었다고 말하는 것이 아니며 , 그 진술은 완벽하게 정확합니다. 그렇다고해서 문제가되는 것은 아니며 사용자에게 영향을주지 않으면 무시하기로 결정할 수 있습니다.

다음과 같은 이유로 발생할 수 없습니다.

• CPU 문제 (또는 오히려 하드웨어 오류가 발생할 수 있음)
• 메모리 문제 (매우 하드웨어 오류는 발생하지만 여러 번 발생하지는 않습니다. 프로세스로 인해 RAM이 부족하지 않음 oom-killed),
• 스왑 부족 ( oom-killer다시).

확장하면, RAM에서 데이터 캐싱 시스템을 박탈하면 더 많은 I / O가 발생한다는 점에서 메모리 부족으로이를 비난 할 수 있습니다. 그러나 "메모리 부족"만큼 간단하지는 않습니다.

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

그런 다음 변경 사항을 커밋하십시오.

sudo sysctl -p

나를 위해 그것을 해결 ....

최근 프로덕션 클러스터 중 하나 에서이 오류를 겪었습니다.

11 월 11 일 14:56:41 xxx 커널 : 정보 : 작업 xfsalloc / 3 : 2393이 120 초 이상 차단되었습니다.

11 월 11 일 14:56:41 Xxxx 커널 : 오염되지 않음 2.6.32-504.8.1.el6.x86_64 # 1

11 월 11 일 14:56:41 xxx : "echo 0> / proc / sys / kernel / hung_task_timeout_secs"는이 메시지를 비활성화합니다.

..

sar 로그를 추가로 확인한 결과 IO 대기 시간이 증가했습니다.

그리고 하드웨어 (물리 디스크)를 확인하자마자 매체 오류와 다른 SCSI 오류가 하나의 물리 디스크에 기록되어 할당 할 리소스가 부족하여 IO를 차단하고있었습니다.

15/11/15 19:52:40 : 종료 된 pRdm 607b8000 flags = 0 TimeOutC = 0 재시도 C = 0 요청 c1173100 응답 60e06040 iocStatus 0048 재시도 0 devId : 3 devFlags = f1482005 iocLogInfo : 31140000

11/11/15 19:52:40 : DM_ProcessDevWaitQueue : devId = x 프로세스의 태스크 mgmt 11/11/15 19:52:40 : DM_ProcessDevWaitQueue : devId = x 프로세스의 태스크 mgmt

클러스터의 하드웨어 오류 때문입니다.

따라서 코어 파일을 확인할 수 있고 ipmi 유틸리티가 있으면 ipmiutil / ipmitool sel elist 명령을 확인하여 문제를 확인하십시오.

감사합니다, VT

클라우드 공급자의 모니터링 인터페이스로 이동하여 스토리지에 지정된 최대 IOps를 초과하지 않았는지 확인할 수 있는데, 이는 캐시 데이터를 플러시하는 데 시간이 오래 걸린 이유를 설명합니다.
최대 IOps는 스토리지 속성 페이지에서 사용할 수 있습니다.