워치독(의도적으로 시스템에 과부하를 주는 스크립트 또는 명령)을 테스트하는 좋은 방법은 무엇입니까?

워치독(의도적으로 시스템에 과부하를 주는 스크립트 또는 명령)을 테스트하는 좋은 방법은 무엇입니까?

하드웨어 감시 기능이 있는데 실제로 작동하는지 테스트할 수 있는 좋은 방법이 있나요? 내 시스템을 모든 리소스를 사용하는 무한 루프로 설정하거나 하드웨어 감시를 트리거하는 유사한 표준 스크립트나 유사한 스크립트가 있습니까?

답변1

워치독을 테스트하는 간단한 방법은 커널 패닉을 유발하는 것입니다. 이 작업은 루트로 수행할 수 있습니다.

echo c > /proc/sysrq-trigger

커널은 워치독 핑에 대한 응답을 중단하므로 워치독이 실행됩니다.

SysRq는 사용자가 누를 수 있는 "마법의" 키 조합이며 커널이 완전히 잠기지 않는 한 무엇을 하든 이에 반응합니다. /proc/sysrq-trigger여기서 했던 것처럼 문자를 에코하여 사용할 수도 있습니다 .

이 경우 문자는 c시스템 충돌을 수행하고 충돌 덤프(구성된 경우)를 수행한다는 의미입니다.

다음 문서를 찾을 수 있습니다SysRq 여기.

답변2

워치독이 제대로 작동하고 사용자 공간에서 워치독 프로세스를 실행하고 있는지 테스트하려면(커널 스레드에서 실행되는 커널 워치독과 반대) 프로세스를 종료하거나 중지하면 됩니다. 이는 응답하지 않는 시스템을 시뮬레이션합니다. 하드웨어 워치독은 다음과 같습니다.아니요하드웨어가 타이머를 재설정하는 곳입니다. 하드웨어 워치독은 하드웨어에 타이머를 구현하는 워치독입니다. 어느 쪽이든 소프트웨어는 감시 타이머를 주기적으로 재설정합니다.

워치독이 장착되어 있지만 활성화되지 않았는지 테스트하는 또 다른 일반적인 방법은 간단히 켜는 것입니다.

# cat >> /dev/watchdog

이는 감시 프로세스가 실행되고 있지 않다고 가정합니다. 일단 켜지면 감시 타이머가 시작됩니다. cat방금 열렸으며 아무 것도 기록되지 않았기 때문에 (읽고 stdin있고 입력이 오지 않기를 기다리고 있음) 결국 타이머가 만료되고 시스템이 재설정됩니다.


무거운 하중에도, 일반적으로 시스템은 감시 시간이 초과될 때까지 잠기지 않습니다. Watchdog은 시스템이 실패할 경우 시스템을 다시 시작하도록 설계되었습니다.복구할 수 없는, 또는 적어도 일정 기간 내에 복원할 수 없습니다. 이는 극도로 높은 메모리 압력이나 장치의 차단된 스왑 대상과 같은 하드 잠금으로 인해 발생할 수 있습니다.

컴퓨터에는 CPU 코어 수가 제한되어 있습니다. SMT를 무시하면 각 코어는 특정 순간에 하나의 프로세스만 실행할 수 있습니다. 프로세스가 너무 많은 시간을 차지하는 것을 방지하기 위해 커널 스케줄러는 다음을 지정합니다.시간 조각. 각 프로세스는 해당 시간 조각 내에서 실행될 수 있지만 일단 만료되면(또는 프로세스가 자발적으로 차단 시스템 호출을 수행하거나 수행하면) 커널은 자동으로 이를 선점하고 다른 프로세스 실행을 시작합니다. 이 디자인은 프로세스가 다음을 수행할 수 있음을 의미합니다.안 돼요단순히 CPU를 많이 사용하여 다른 프로세스가 실행되는 것을 방지합니다. 커널이 건강하다면 마찬가지입니다.

사용자 공간에서 실행되는 프로세스는언제나커널에 의해 선점되었습니다. 이런 일이 일어나는 것을 막을 수는 없습니다. 전체 시간 조각을 사용하여 시스템 로드를 100%로 유지할 수 있지만 커널이 다른 프로세스의 차례를 수행하는 것을 막을 수는 없습니다. 그러나 페이지 폴트, 시그널, 시스템 호출 등으로 인해 커널 공간에서 실행 중인데 커널이 요청을 이행하지 못하고 사용자 공간으로 돌아갈 수 없게 되는 문제가 발생하면 프로세스가 잠기고 스케줄러가 실행될 기회를 얻을 수 없습니다. 모든 코어에서 이런 일이 발생하면 워치독은 실행될 기회가 없으며 결국 타이머가 시간 초과되어 프로세스에서 시스템이 재설정됩니다.

답변3

과거에는 이로 인해 perl -e '1 while 1'시스템이 매우 혼잡해졌을 것입니다. 그러나 64코어 또는 기타 유형의 다중 프로세서 시스템에서는 이는 단순히 골치 아픈 일이며 실제로 메모리를 소비하지 않습니다. (Linux에서) 한 가지 접근 방식은 메모리 부족 킬러 이전에 프로세스를 생성하여 시스템이 결국 충돌하도록 하는 것입니다. 이를 달성하는 한 가지 방법은 단일 프로세스에 가능한 한 많은 메모리를 할당하고, 여러 작업자 스레드를 생성하고, 해당 스레드가 할당된 모든 메모리에 대해 무작위 메모리 액세스를 수행하도록 하는 것입니다. 그런 다음 이러한 프로세스를 시작하려고 시도하는 일부 쉘 루프가 있으며, 모두 가능한 한 많은 메모리를 차지합니다. 누군가 이 내용을 따라 스크립트를 작성했을 수도 있습니다.

https://github.com/thrig/scripts/blob/master/bench/usemem.c

rand()이는 스레드의 호출로 대체 될 수 있는 사용자 정의 RNG를 사용합니다 . Linux에서 컴파일된 지 꽤 오래되었으므로 -DLinux에서 컴파일러를 달래기 위해 다양한 정의가 필요할 수 있습니다.

관련 정보