Linux 용 성능 카운터는 모든 성능 분석을위한 프레임 워크를 제공하는 새로운 커널 기반 하위 시스템입니다. 하드웨어 수준 (CPU/PMU, 성능 모니터링 장치) 기능 및 소프트웨어 기능 (소프트웨어 카운터, 추적 점)도 다룹니다. 2.6.33 이후, 커널은 개발자가 시스템 런타임 정보를 수집하기 위해 커널 카운터를 생성 할 수 있도록 'perf_event_create_kernel_counter'커널 API를 제공합니다. 필자가 가장 우려하는 것은 트레이스 포인트/ftrace가 활성화되었을 때 전체 시스템 성능에 미치는 영향입니다. 내가 찾을 수있는 문서가 없습니다. 나는 ftrace가 동적으로 패치 코드에 의해 구현되었다는 말을 들었습니다. 시스템을 크게 느리게 할 것입니까?Linux 커널의 Perf 이벤트 하위 시스템 성능 오버 헤드
사람들이 유용하다고 생각하고 흥미로운 정보를 수집 할 수 있다는 점을 고려하면 이러한 것들을 넣을 수 있습니다. 그것이 목표라면, 괜찮아.
그러나 목표가 인 경우 더 높은 성능의 소프트웨어 인을 조정하면 진단상의 가치가 거의 없습니다.
그들은 흥미로운 측정을 제공 할 수 있지만 은 무엇을 수정해야하는지 알려주지 않습니다..
내 목표는 프로덕션 시스템에서 장기 프로파일 링을 실행하므로 성능 오버 헤드가 가장 중요합니다. –
@Bo : 건강 상태를 장기간 모니터링하기 위해서는 고주파로 수집 된 정보가 필요하지 않을 수도 있습니다. 전반적인 타이밍 문제 일 것입니다. 높은 빈도로 정보를 수집하여 퍼포먼스에 영향을 미칠만한 것이 있다면, 아마도 그것이 당신이 이해할 수있는 것보다 더 많은 정보 일 것이라고 생각합니다. 일반적으로 사람들은 "병목 현상"을 찾기 위해 "도구 사용"(오버 헤드가 걱정됩니다)을 수행합니다 (좋은 방법은 아닙니다). –
동적 패치가 활성화되지 않은 트레이스시 오버 헤드를 최소화하는 방법으로 사용된다. PMU 기반 하드웨어 카운터의 오버 헤드는 샘플링 할 이벤트의 수와 빈도에 따라 달라집니다. 원하는 수준에 따라 적절한 구성을 찾을 수있을만큼 충분히 낮을 수 있습니다. 관심있는 정보 수집을 활성화하고 빈도를 신중하게 설정 한 다음 오버 헤드가 수용 가능한지 경험적으로 확인합니다.
perf는 가능한 한 적은 영향을 미치기위한 것이고, 얼마나 많은 작업을 수행 하느냐에 달려 있습니다. – Spudd86