영향을 받는 시스템은 vSphere에서 실행되는 가상 시스템이자 프로덕션 서버이므로 문제가 표면화되면 일반적으로 문제 해결 시간이 존재하지 않습니다. 재부팅 후 문제는 사라졌고, 일주일 정도 지나니 시스템이 안정적으로 돌아가는 것 같았습니다. 이런 일이 다시 발생하면 무엇을 해야 할지 또는 찾아야 할지에 대한 몇 가지 아이디어를 찾고 있습니다(현재 패턴이 사실이라면 아마도 이번 주 목요일이나 금요일쯤).
VM이 핑에 잘 응답하지만 여전히듣다http/s 요청(apache2)에 사용되지만 응답하지 않습니다. 또한 SSH를 수신하지만 세션을 닫기 전에 인증을 묻는 메시지를 표시하지 않습니다.
명령을 제출한 후 "로컬" 콘솔이 즉시 중단됩니다. 그때까지는 시스템에 요청하는 경우에만 원하는 내용을 입력할 수 있습니다.하다작동이 멈췄습니다. 여기에는 파일 이름 등에 탭 완성 기능을 사용하려는 시도가 포함됩니다. 다른 가상 터미널 중 하나로 전환하여 사용자 이름과 비밀번호를 입력할 수 있지만... 시스템이 다시 중단됩니다.
/var/log의 로그에는 충돌에 대한 정보가 없습니다(다른 곳을 볼 수 있는 포인터가 있습니까?). 로그 파일의 마지막 메시지는 실제 문제가 발생하기 오래 전에 기록되었습니다.
추가 정보:
이 문제가 발생하면 가상 머신의 로컬 콘솔에 아무 것도 인쇄되지 않습니다. 가상 머신에는 LSI Logic Parallel vSCSI를 통해 연결된 1TB 볼륨(씩 프로비저닝, 지연된 제로화)이 있습니다. 데이터 저장소 자체는 몇몇 다른 ESXi 호스트에도 서비스를 제공하는 대규모 NAS이며, 이러한 상황이 발생하더라도 다른 게스트는 영향을 받지 않습니다.
이 문제가 발생하면 vCenter/vSphere는 비정상적으로 높은 CPU 또는 메모리 사용률을 표시하지 않습니다.
적어도 한 번은 SFTP를 통해 서버에 액세스하려는 누군가가 이를 발견하기 전까지 8시간 이상 지속되는 경우가 있었습니다.
sourcejedi의 제안에 따라 이제 콘솔 로깅 임계값을 5로 낮추고 가상 머신의 로컬 콘솔에서 /dev/kmsg로 전송된 메시지를 볼 수 있음을 확인했습니다. 변경하기 전에는 이러한 메시지가 표시되지 않았으므로 커널이 무언가를 말하려고 시도했지만 본 적이 없을 수도 있습니다.
ESXi 호스트에 무료 리소스가 있었기 때문에 VM도 복제하여 별도의 격리된 네트워크에 배치했습니다. 이 문제가 발생하면 그 과정에서 생산 서비스가 중단되는 것에 대해 걱정할 필요 없이 문제를 해결하는 데 더 많은 시간을 갖게 됩니다.
더 많은 정보가 나오면 업데이트하겠습니다. 지금까지 도와주신 모든 분들께 감사드립니다!
답변1
- 가설
- 지시하다
- 어리석은 해킹(작업이 파일 시스템/디스크 액세스로 인해 중단된다고 가정)
1. 가정
1.1) 기본적으로 Linux 커널에는 다양한 유형의 충돌 또는 중단을 보고하는 코드가 있습니다.
둘 다 현재 문제를 표시하고 "로컬 콘솔"에 호출 체인을 인쇄합니다. 근본 원인을 밝히지 못할 수도 있으며 이 코드는 결코 100% 신뢰할 수 없습니다. 그러나 대개는 무언가를 얻게 되며, 아무것도 없는 것보다는 훨씬 낫습니다.
따라서 콘솔에서 이러한 커널 로그 메시지를 볼 수 있는지 다시 확인해야 합니다! 자세한 내용은 다음 섹션에서 확인하세요.
1.2) 커널 자체는 여전히 키 입력과 네트워크 패킷에 응답하고 있으므로 보류 중인 작업 감지기가 여기서 작동했으면 좋겠습니다.
커널 스레드와 인터럽트가 여전히 실행 중인 것처럼 들리지만 사용자 공간 프로세스가 정지됩니다. 이러한 증상은 프로세스가 실제 파일 시스템에 액세스하려고 할 때 중단되는 것과 일치합니다. 프로세스가 몇 분 동안 정지되면 커널은 "보류 중인 작업" 메시지와 호출 체인을 인쇄합니다.
1.3) 또한 사용자 프로세스가 완전히 일시 중지되지는 않았지만매우천천히, 그리고 그들이 발전하는 것을 볼 수 있을 만큼 "충분히 오래" 기다리지 마십시오.
기계식 HDD가 장착된 Linux PC를 사용해 본 경험이 있다면 이 이야기가 익숙할 것입니다. :-). 하지만 이것은 책상 위의 PC가 아니기 때문에 시끄러운 하드 드라이브나 영구적으로 켜져 있는 디스크 활동 표시등을 눈치채지 못할 것입니다 :-).
저는 서버 관리 경험이 없습니다. 하지만 이러한 문제를 감지하려면 모니터링 소프트웨어를 사용해야 한다고 생각합니다. 이상적으로는 사용자에게 눈에 띄는 문제가 발생하기 전이라도 말이죠 :-).
예를 들어, 시스템 메모리 사용량을 모니터링하면 점진적인 "메모리 누수"가 발생하고 시스템이 종료될 때까지 자체 교체를 시작하는지 확인할 수 있습니다. 이 문제가 발생하지 않기를 바랍니다. 예를 들어, login교체된 경우 콘솔 로그인 속도가 느려지거나 비밀번호를 묻는 메시지가 표시될 수도 있습니다.
충분히 세분화된 모니터링이 있는 경우 관찰된 오류가 발생하기 전에 디스크 IO 초의 증가를 감지할 수 있습니다.
2. 사용 지침
2.1) 커널 패닉이 인쇄되는지 알 수 있도록 "로컬 콘솔"이 기록되거나 적어도 지속됩니까? 실제로 그래야 하지만 시뮬레이션된 vSphere 등을 사용하면 어떻게 작동할지 잘 모르겠습니다.TV 시리즈편안. 아날로그 비디오 디스플레이만 사용하고 있다면 이미 지속되는 상태입니다.
이 VMWare 기사동일한 가정에 의존하는 것 같습니다.
2.2) 콘솔 로깅을 비활성화하지 않았는지 확인하십시오. 다음 명령을 실행하세요:
sudo sh -c "echo '<3>test' >/dev/kmsg"
콘솔에 "Test"라고 표시되어야 합니다. 아래에서 스택 추적에 대해 논의하는 내용도 참조하세요.
시뮬레이션된 비디오 디스플레이인 경우 일부 충돌 메시지가 화면 상단에서 스크롤되어 사라질 수 있습니다. 커널에 있는 경우추락, Shift+PageUp을 사용하여 위로 스크롤할 수 없습니다. 원칙적으로는 롤백을 구현하는 에뮬레이트된 직렬 콘솔을 갖는 것이 더 유용할 것입니다.
커널 패닉의 경우 위의 VMWare 링크에 몇 가지 다른 크래시 덤프 제안이 있습니다.
2.3) 비밀번호를 입력한 후 정지되는 현상은 디스크가 응답하지 않는 것처럼 들립니다. 제 생각에는 Linux SCSI 작업이 시간이 지나면 시간 초과가 발생하고 시간 초과가 커널 오류로 기록되므로 Linux에서 이를 콘솔에 인쇄하는 것 같습니다. 파일 시스템이 SCSI 프로토콜이나 다른 프로토콜을 사용하여 마운트되어 있습니까?
2.4) 또한 기본적으로 커널은 보류 중인 작업을 감지하고 다음 메시지를 인쇄합니다 task bash:999 blocked for more than 120 seconds. 다음은 호출 체인("스택 추적")입니다. 그래도 콜 체인 부분은 커널의 "기본 로그 수준"을 사용하여 기록되는 것 같은데, 이는 일반적으로 수준 4(경고)를 의미합니다.
보류 중인 작업 메시지의 호출 체인 부분을 보려면 콘솔 로그 수준을 높여야 할 수도 있습니다.이상예를 들어 레벨 4 dmesg -n 5.
보류 중인 작업 메시지를 비활성화하지 않았는지 확인하려면: cat /proc/sys/kernel/hung_task_timeout_secs예를 들어 양수가 표시되어야 합니다 120.
보류 중인 작업 메시지를 인쇄하지 않음네트워크 파일 시스템이 중단됩니다.. 보류 중인 작업은 "중단할 수 없고" "종료할 수 없는" 경우에만 인쇄됩니다. NFS에 정지된 프로세스가 종료될 수 있음. 이러한 중단을 유발할 수 있는 네트워크 파일 시스템을 사용하는 경우 이 점을 고려했을 수 있습니다. (그리고 어떻게든 NFS 서버에 대한 연결을 테스트하는 대신오직테스트 중단된 VM을 사용 ping하면 질문에 이 모든 내용이 언급됩니다. :-). NFS 서버가 다른 VM에 응답하는 것처럼 보이지만 이 VM에 보류 중인 작업 메시지가 표시되지 않는 경우 sysrq+T를 사용하여 조사해 볼 수 있습니다(아래 참조).
보류 중인 작업 메시지는 Debian Linux 버전에서 기본적으로 활성화됩니다. (어떤 이유에서인지 내 Fedora Linux 커널에는 빌드 시 보류 작업 감지기가 전혀 포함되어 있지 않습니다. RHEL 및 SLES 커널에 포함된 것처럼 보이지만 FIXME).
정지된 작업 메시지를 검색했을 때 정지된 서버 및 IO 오류 메시지가 공통 주제인 것 같았습니다. :-).
그리고 리눅스 sysrq. 직렬 콘솔이 있지만 연결 후에만 인쇄된 출력을 캡처할 수 있는 경우 sysrq+T를 사용하여 보류 중인 작업을 찾아볼 수 있습니다. 그러면 다음에 대한 정보가 덤프됩니다.모든시스템의 작업이므로많은콘솔로 출력합니다. 따라서 콘솔이 비디오 모니터인 경우 이는 그다지 유용하지 않을 수 있습니다. 그리고 작동 중인 프로덕션 시스템에서 테스트해서는 안 됩니다! 일부 배포판에서는 sysrq물리적 보안상의 이유로 기본적으로 이를 비활성화합니다. 데비안은 sysrq활성화된 상태로 유지됩니다. 물론 보안 체크리스트를 사용하여 를 비활성화하라고 지시했을 수도 있습니다 sysrq.
2.4) 원래 질문에서는 관찰된 오류 이전에 또는 시스템이 자주 과부하되지 않았음을 보여주기 위해 "응답성"에 대한 정량적 모니터링을 인용하지 않습니다(최종 확장일 수 있음).
다양한 서비스의 서비스 "응답성"에 대한 정량적 모니터링의 가치를 고려하십시오. 여기에는 SSH 서버에 로그인하는 것이 포함될 수 있습니다. 시스템 활용도 수준, 대기 시간, 초당 네트워크 패킷도 있습니다.
PS 둘 다디스크 정체 %그리고"CPU 대기"저주받을 수도 있습니다. 또한 현재 디스크 대기 시간과 IOPS를 모니터링하고 싶습니다. (그러나 현재 Debian 9.x 커널은 디스크 사용량 비율에 상대적으로 민감해야 합니다).
위의 답변과 VMware 링크는 알고 있어야 하거나 적어도 존재한다는 것을 알아야 하는 몇 가지 표준 도구를 설명합니다.
3. 어리석은 해킹(작업이 파일 시스템/디스크 액세스로 인해 중단된다고 가정)
아래 세부 사항은 어리석은 해킹입니다. 때때로 당신에게 필요한 것은 멍청한 해커뿐입니다. 나는 단지 당신이 이것에 의지해야 한다면 아마도 당신이 하고 있는 방식에 해결해야 할 몇 가지 결함이 있음을 나타낼 것이라고 말하는 것입니다. :-P.
시스템이 "준응답" 상태일 때 실행하려는 일부 쉘 테스트가 있는 경우 mlock()의 busybox쉘을 실행해 볼 수 있습니다. 예를 들어아니요정적으로 연결된 비지박스 사용이 LD_PRELOAD mlock 해커. 그런 다음 (exec -a ls /proc/self/exe /)예를 들어 busybox 명령을 실행하십시오 . 아마도 가장 안전한 방법은 다음과 같습니다.
# prevent you running any normal program by mistake!
OLDPATH="$PATH"
PATH=
# run a busybox builtin
b() (
local command="$1"
shift
exec -a "$command" /proc/self/exe "$@"
)
# run normal program in the background, in case it hangs
p() {
local PATH="$OLDPATH"
exec "$@" &
}
b dmesg이렇게 하면 캐시되지 않은 파일을 읽지 않고도 실행할 수 있습니다 :-).
(누군가가 1) 중단된 파일 시스템을 마운트하는 것을 관리하고 2) 중단되지 않고 액세스 조차 할 수 없도록 /마운트 하는 경우 이는 문제가 발생합니다 . 나는 이것이 가능성이 낮고 방어하기가 더 고통스러울 것이라고 생각합니다. )/proc/proc
b ps -o stat,pid,args프로세스 상태가 표시됩니다. D이는 "중단되지 않은 상태"를 의미합니다. 일반적으로 디스크 또는 네트워크 파일 시스템을 기다리고 있습니다. 그러면 b cat /proc/999/stackPID 999가 커널에서 대기 중인 위치가 표시됩니다.
cd /sys/class/block/ && b grep -H . */inflight각 디스크에 대해 진행 중인 읽기 및 쓰기 수가 표시됩니다.