저는 perf
linux-2.6.36-gentoo-r4를 사용하고 있습니다. 0으로 설정 /proc/sys/kernel/perf_event_paranoid
하면 문제가 발생하지 않습니다.
프로파일링 중이던 장기 실행 애플리케이션이 불특정 이유로 충돌하는 경우가 종종 있었기 때문에(작동이 중지된 이유에 대한 정보를 찾을 수 없었음) 시스템 전체 프로파일링에 성능 이벤트를 사용하게 되었습니다.
관련 애플리케이션은 MPI(Message Passing Interface)를 사용하여 통신하고 병렬 수치 계산을 수행합니다. 애플리케이션을 실행하기 전에(을 사용하여 mpirun
) 다음 위치에서 시스템 전체 프로필 데이터 로깅을 시작했습니다.하나실행 중인 노드 수:
$ perf record -o perf.all.cycles,graph.data -g -e cycles -a &
애플리케이션이 충돌했다는 것을 알았을 때 perf
작업을 종료했습니다.
그것은 떠났다
$ du -sh perf.all.cycles,graph.data
14G perf.all.cycles,graph.data
14GB 데이터. 아쉽게도 전환은 perf report
지원되지 않습니다 -a
.
도구를 사용하여 perf
시스템 전반의 분석 데이터를 분석하는 방법?
2011.08.12에 추가됨
간단히 실행하면 perf report
유용한 출력이 생성되지 않습니다.
$ perf report -i perf.all.cycles,graph.data
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
14GB 프로필 데이터의 전체 출력입니다...
답변1
MPI를 사용하여 계산을 분산시키는 경우 MPI 인식 도구를 사용하면 더 스마트한 결과를 얻을 수 있습니다. 분산 애플리케이션의 경우 하나의 MPI 프로세스가 다른 프로세스의 입력을 기다리는 동안 유휴 상태인 로드 불균형 문제가 발생할 수 있습니다. 이 MPI 프로세스를 정확하게 분석했다면 성능 분석은 완전히 잘못된 것입니다.
따라서 첫 번째 단계는 일반적으로 프로그램의 통신 및 로드 밸런싱 패턴을 이해하고 필요한 워크로드(예: 레벨 0의 CPU 집약적)를 제공하는 샘플 입력을 식별하는 것입니다. 예를 들어, 밉통신 패턴, 각 MPI 호출에 소요된 시간 등에 대한 매우 완전한 보고서를 생성하는 MPI 분석 도구입니다.
그런 다음 하나 이상의 선택된 MPI 수준에서 코드 분석 도구를 실행할 수 있습니다. 어쨌든 단일 MPI 레벨에서 이를 사용하는 것은 좋은 생각이 아닐 것입니다 perf
. 그 측정에는 MPI 라이브러리 코드의 성능도 포함되며 이는 아마도 원하는 것이 아닐 수 있기 때문입니다.
답변2
perf report
-a
스위치는 결과를 보고할 필요가 없습니다 perf record -a
. 당신이 해야 할 일은 를 입력하는 것 뿐입니다 perf report
.
즉, 충돌을 추적하기 위해 14G의 분석 데이터를 분석하는 것은 이상해 보입니다. 디버거를 연결하는 것은 어떻습니까?