2010-05-12 13 views
15

Me gustaría crear un perfil de mi aplicación C++ en Linux. Me gustaría saber cuánto tiempo gastó mi aplicación en el procesamiento de la CPU en comparación con el tiempo pasado en bloque por IO/inactivo.Cómo perfilar mi aplicación C++ en Linux

Sé que hay una herramienta de perfil llamada valgrind en Linux. Pero se rompe el tiempo dedicado a cada método, y no me da una idea general de cuánto tiempo se gasta en el procesamiento de la CPU en lugar de inactivo. O hay una forma de hacerlo con valgrind.

+4

tiempo + gprof + valgrind y amigos + oprofile – Tom

+0

Digamos 'tiempo' dime que mi aplicación tarda 20 sec. ¿Cómo averigua valgrind cuánto tiempo gasto en procesar CPU VS cuánto tiempo en esos 20 segundos estoy inactivo? Entiendo que valgrind desglose el costo de cada función cuando la CPU está procesando. Quiero averiguar la relación entre el tiempo de procesamiento de la CPU VS tiempo de inactividad (esperar tráfico de red, llamadas IO, etc.). – richard

Respuesta

3

Puedo recomendar la herramienta valgrindcallgrind junto con KCacheGrind para la visualización. KCacheGrind hace que sea muy fácil ver dónde están los puntos de acceso.

Nota: Ha pasado demasiado tiempo desde que lo usé, así que no estoy seguro de si podrá obtener tiempo de espera de E/S. Tal vez junto con iostat o pidstat podrá ver dónde pasó todo el tiempo.

+0

Callgrind solo registra la hora del sistema, no el tiempo de inactividad. –

6

Consulte oprofile. También para más diagnósticos a nivel de sistema, intente systemtap.

+0

El problema de ganar OProfile es que solo mide el tiempo de CPU. El tiempo bloqueado en IO o las llamadas al sistema no aparecerán en sus informes. –

+0

@Caspin: puede deducir la io-hora del reloj de pared. – florin

0

Las herramientas lacayo y/o helgrind en valgrind deberían permitirle hacer esto.

1

callgrind es una muy buena herramienta, pero me encontré con OProfile más 'completo'. Además, es el único que le permite especificar el módulo y/o la fuente del kernel para permitir una visión más profunda de sus cuellos de botella. Se supone que la salida es capaz de interactuar con KCacheGrind, pero tuve problemas con eso, así que usé Gprof2Dot. Puede exportar su callgraph a .png.

Editar:

Oprofile mira al sistema en su conjunto por lo que el proceso sólo será:

[oprofile configuración]

opcontrol --init 
opcontorl --vmlinux=/path/to/vmlinux  (or --no-vmlinux) 
opcontrol --start 

[ejecutar su aplicación aquí]

opcontrol --stop (or opcontrol --shutdown [man for difference] 

luego para comenzar a mirar los resultados mira la página de manual en opreport

+0

¿Necesito compilar mi programa con banderas especiales para que funcione OProfile? – richard

+0

¿Qué es 'vmlinux'? ¿Dónde puedo encontrarlo? – richard

2

LTTng es una buena herramienta para usar en la creación de perfiles completos del sistema.

3

Es posible que desee comprobar Zoom, que es mucho más pulido y con todas las funciones que oprofile y otros. Cuesta dinero ($ 199), pero puede obtener una licencia de evaluación gratuita de 30 días.

2

Si su aplicación simplemente se ejecuta "completamente" (es decir, está usando CPU o esperando E/S) hasta que finaliza, y no hay otros procesos compitiendo, simplemente haga time myapp (o quizás /usr/bin/time myapp, que produce un poco salida diferente al shell incorporado).

Esto le dará algo como:

real 0m1.412s 
user 0m1.288s 
sys  0m0.056s 

En este caso, el usuario sys + (kernel) representan el tiempo para casi todo el tiempo real y no es sólo 0.068s desaparecidos ... (probablemente el tiempo pasado cargando la aplicación y sus libs de soporte).

Sin embargo, si usted fuera a ver:

real 0m5.732s 
user 0m1.144s 
sys  0m0.078s 

entonces su aplicación gastaron 4.51s no consumir CPU y presumiblemente bloqueado en IO. ¿Cuál es la información que creo que estás buscando?

Sin embargo, cuando esta técnica de análisis sencillo se descompone es:

  • Aplicaciones que esperan en un temporizador/reloj u otro estímulo externo (por ejemplo aplicaciones GUI por eventos). No se puede distinguir el tiempo de espera en el reloj y el tiempo de espera en el disco/red.
  • Aplicaciones multiproceso, que necesitan un poco más de pensamiento para interpretar los números.
+0

Bueno, creo que estoy buscando la misma herramienta, pero debo decir que esta no es una publicación muy informativa. El problema es encontrar áreas de código, que son (por alguna razón desconocida) esperando algo, determinar los motivos de la espera e intentar eliminarla. Por ejemplo, tengo un software de red de tres partes, necesito mejorar el rendimiento, pero incluso con una carga de trabajo extrema, el sistema pasa la mayor parte del tiempo esperando. –

-1

See this post.

And this post.

Básicamente, entre el momento en el programa se inicia y cuando termina, tiene una pila de llamadas. Durante I/O, la pila finaliza en una llamada al sistema. Durante el cálculo, termina en una instrucción típica.

De cualquier manera, si puede probar la pila al azar, puede ver exactamente por qué está gastando ese tiempo.

El único punto restante es que miles de muestras pueden dar una sensación de confianza, pero no le dirán mucho más de 10 o 20 muestras.

+0

@Downvoter: ¿me importa explicarme? –

0

google-perf-tools - alternativa mucho más rápida que callgrind (y puede generar resultados con el mismo formato que callgrind, para que pueda usar KCacheGrind).

Cuestiones relacionadas