☰

CPU에서 단기 CPU 집약적 프로세스 추적/모니터링

tag-icon • tag-icon performance monitoring time top real-time
CPU에서 단기 CPU 집약적 프로세스 추적/모니터링

그래서 한동안 이 문제를 다루어 왔지만 이 문제를 해결할 도구를 찾는 데 어려움을 겪고 있습니다. 이 문제가 존재한다고 상상해야 합니다. 내 문제의 기본은 다음과 같습니다.

  • 우리는 preempt-rt 패치로 4코어 RHEL5/centos5를 실행하고 소수의 애플리케이션(fifo 스케줄링, 높은 우선순위 등)에 대해 합리적인 결정성을 보장하기 위해 몇 가지 작업을 수행하려고 노력합니다. 어쨌든, 우리는 최근 기본값보다 약간 높은 우선순위로 PTPv2 클라이언트를 실행하기 시작했습니다. PTPv2 클라이언트의 CPU 시간이 부족하면 실제로 꽤 무서운 부작용이 발생할 수 있다는 것이 밝혀졌습니다. 세부 사항을 살펴보지 않고도 비교적 짧은 시간 동안 PTP 데몬을 바인딩한 CPU를 무언가가 잡아먹고 있다는 것을 알 수 있습니다(기존 로깅으로는 이를 캡처할 수 없었기 때문입니다). 따라서 짧은 버전은 이 PTP 클라이언트를 사용자 모드(호출 사용 daemon)에서 시작하고 이를 특정 CPU에 바인딩한 taskset다음 해제하는 것입니다. 몇 시간 마다,무엇PTP 클라이언트를 선점하거나 약 10ms-500ms 동안 어떤 이유로든 실행을 방지합니다.

나는 CPU PTP가 실행되고 있다는 것을 알고 있기 때문에 해당 CPU에서 무슨 일이 일어나고 있는지 추적하는 것이 상대적으로 쉬울 것이라고 생각했습니다. 불행하게도 특정 CPU의 동작을 추적하는 것은 쉽지만주어진 시간에(상단 및 친구) 또는 최근 시간의 집계(sar 및 친구)를 포함하지만 짧은 시간(밀리초 범위)만 지속되지만 드물게(매번) 지속되는 성능 스파이크를 포착하는 것은 놀라울 정도로 어렵습니다. 몇 시간 정도). 나는 다음을 시도했습니다(그러나 나는 그것을 올바르게 사용했다고 주장하지 않습니다! 따라서 내가 실수로 올바른 도구를 사용했다고 생각되면 알려주십시오):

  • htop/top: top과 친구들은 무슨 일이 일어나고 있는지 이해하는 데 매우 유용합니다.지금. 멀티 코어 시스템에서는 프로세스가 마지막으로 실행된 CPU를 알려주는 옵션을 살펴보고 나머지는 무시해야 하기 때문에 이것이 약간 더 어려워집니다. 그러나 얼마 전에 문제가 발생했거나 짧은 기간 동안 발생한 경우 아무것도 하지 않고는 내가 하고 싶은 일을 하는 것이 어려운 것처럼 보였습니다.많은최상위 로깅,매우자주. Htop은 미학적으로 더 보기 좋지만 적어도 내가 원하는 기능에 대해서는 거의 동일한 기능을 제공하는 것 같습니다.

  • sar: sar는 시간 경과에 따른 활동을 추적할 수 있으므로 더 적합한 것 같습니다. 그런데 사르는 당신에게 말을 아주 잘하는 것 같습니다.어떻게시스템이 5분, 10분, 15분 전에 실행 중이었지만 실행되지 않았습니다.왜그것이 행동하는 방식입니다. 즉, 어떤 프로세스(사용자 "프로세스"라도)가 문제를 일으키는지 파악하기 어렵습니다. 어쨌든 로깅과 구문 분석을 조사 중입니다.위치수동 데이터.

  • mpstat: mpstat는 보고 싶은 내용을 관심 있는 CPU로 쉽게 제한할 수 있다는 점에서 훌륭합니다. 그러나 그것이 제공하는 정보는 상당히 불투명합니다.만약에기본적으로 (비교적 빠른 이벤트를 캡처하기 위해) 지속적으로 실행되도록 mpstat를 설정했습니다.만약에내 관리자는 활동이 급증하는 것을 보고 있지만 그 활동이 어디에서 왔는지 알 수 있는 방법이 많지 않습니다(제가 누락한 것이 있는 경우가 있어서 제가 여기 있는 것입니다!).

그렇다면 이 문제를 어떻게 해결합니까? 내 사용자 영역 PTP 데몬이 기본 수준에서 내가 이해한 바에 따르면 네트워크에서 절대 시간을 가져오고 PTP가 해당 시간에 가까워지기 위해 클록 주파수와 틱을 왜곡하려고 시도하기 때문에 엉망이 된 것을 알고 있습니다. 그러나 어떤 이유로(예: PTP 기아/한동안 실행되지 않음) 현재 시간과 기본 시간이라고 생각하는 시간의 차이가 매우 큰 경우(보통 > 1초) 계속해서 진행되고 설정됩니다. / 시계를 왜곡하지 않고 강제로 실행합니다. 이는 시계의 큰 변화(이 경우 ~200ms 이상)를 원하지 않는 애플리케이션에 문제를 일으키지만 시계가 0.5초 정도 충돌하는 것을 보았습니다. 즉시 또는 그 이상 변경됨)... 그게 바로 제가 본 것입니다. 내가 말했듯이 우리는 작업을 CPU로 설정하므로 어떤 CPU에서 실행되고 있는지 알 수 있습니다. grub.conf에 isolcpus가 있고 init에 의해 생성된 하위 프로세스가 특정(다른) CPU에서 생성되도록 init의 선호도도 변경했습니다. 따라서 이론적으로는 어떤 CPU PTP가 실행되는지 완전히 제어할 수 있습니다. 여전히 PTP를 차단하고 있는데 예상한 대로 패킷을 포착하고 이를 추적하려고 머리를 쥐어짜고 있었습니다.

참고로, 네, 저는 우리가아마도PTP는 커널 모듈로 실행되어야 하며 PTP 데몬을 높은(낮은) 우선순위의 FIFO로 보내서 이 문제를 피할 수 있었습니다. 이는 문제를 해결한 것 같지만 이것이 더 중요합니다. 특정 CPU에서 시간 경과에 따른 시스템 성능을 추적하는 데 관련된 일반적인 문제입니다. 그런 문제를 어떻게 해결하겠습니까?

감사합니다! 어떤 도움이라도 대단히 감사하겠습니다.

답변1

나는 당신과 비슷한 문제를 겪었습니다 (Nagios에 대해 단기간에 집에서 작성한 모니터링 응용 프로그램을 사용함). 내가 생각해낸 해결책은모으다bash while 루프와의 조합.

이런 프로세스 이름으로 Collectl을 깨울 수 있기 때문입니다.

collectl -sZ -i.1:.1 --procfilt f[your process name]

그리고 어떤 프로세스를 호출할지 확실히 알고 있으므로 이를 다음과 같은 루프에 넣습니다.

for((i=1;i<10000;i++)); do nohup /path/to/your/app & done

이것이 귀하의 요구 사항에 맞는지 확실하지 않습니다. 또한 모든 가상/대기 머신에서 테스트하는 것이 가장 좋습니다.

답변2

prelic - 당신은 나보다 한 발 앞서 있습니다. 다른 사람들이 질문에 대답하는 것을 보는 것은 항상 좋은 일입니다. 기록을 위해 -i:.1이라고 말할 수 있으며 프로세스가 아닌 데이터에 대해 기본값인 1초를 사용하지만 데이터가 없기 때문에 입력이 줄어듭니다.)

또한 명확하게 말하면 프로세스 이름은 약간 번거롭습니다. f의 경우 일반적으로 작동하는 /proc/pid/stat에 로그인된 이름이 필요합니다. c를 사용하면 명령이나 스위치 경로가 포함된 /proc/pid/cmdline의 모든 항목과 일치합니다. 내 경험상 f를 사용하여 찾을 수 없으면 c를 사용해 보십시오. 나는 당신이 p, P 및 기타 옵션에도 익숙하다고 생각합니까? 나는 그것들을 결코 기억하지 못하므로 항상 그것을 보려면 Collectl --showsubopt를 참조하십시오.

-표시

관련 정보