Análisis y creación de perfiles de la aplicación de subprocesos múltiples

Question

Estamos teniendo una aplicación de subprocesos múltiples que tiene un gran procesamiento de paquetes en varias etapas de interconexión. La aplicación está en C bajo Linux.

Toda la aplicación funciona bien y no tiene pérdidas de memoria o problemas de seguridad de subprocesos. Sin embargo, para analizar la aplicación, ¿cómo podemos perfilar y analizar los hilos?

En particular, esto es lo que nos interesa:

1. el uso de recursos realizado por cada hilo
2. frecuencia y oportunidad con que las discusiones estaban teniendo contenciones para adquirir bloqueos
3. Monto de los gastos generales debido a la sincronización
4. cualquier cuello de botella en el sistema
5. lo que es el mejor rendimiento del sistema podemos obtener

¿Cuáles son las mejores técnicas y herramientas disponibles para la misma?

Answer 1

1) No sé. Hay algunos perfiladores disponibles para Linux.

2) Si está canalizando, cada etapa debe hacer un trabajo suficiente para garantizar que la contención en las colas P-C sea mínima. Puede descubrir esto con algunos tiempos: si una etapa tarda 10 ms + en procesar un paquete, puede olvidarse de los problemas de contención/bloqueo. Si lleva 100uS, debe considerar amalgamar un par de etapas para que cada etapa haga más trabajo.

3) Igual que (2), a menos que haya un problema de sincronización por separado con algunos datos globales o lo que sea.

4) Dumping/logging el conteo de la cola cada segundo sería útil. La cola más larga estará antes del escenario con el cuello más estrecho.

5) No tengo idea: no sé cómo funciona tu sistema actual, en qué hardware se está ejecutando, etc. Hay algunas optimizaciones "normales": se eliminan las llamadas del administrador de memoria con grupos de objetos, añadiendo hilos adicionales a etapas con el cargas de CPU más pesadas, cosas así, pero "cuál es el mejor rendimiento del sistema que podemos obtener", demasiado etéreo como para decirlo.

Answer 2

Trabajé en un sistema similar hace algunos años. Así es como lo hice:

Paso 1. Deshágase de los que toman el tiempo innecesarios en los subprocesos individuales. Para eso usé this technique. Esto es importante porque el sistema general de mensajería está limitado por la velocidad de sus partes.

Paso 2. Esta parte es un trabajo duro pero vale la pena. Para cada hilo, imprima un registro con sello de tiempo que muestre cuándo se envió, recibió y actuó cada mensaje. A continuación, combine los registros en una línea de tiempo común y estudíelo. Lo que está buscando es a) retransmisiones innecesarias, por ejemplo, debido a tiempos de espera, b) retraso adicional entre el momento en que se recibe un mensaje y el momento en que se actúa sobre él. Esto puede suceder, por ejemplo, si un hilo tiene múltiples mensajes en su cola de entrada, algunos de los cuales pueden procesarse más rápidamente que otros. Tiene sentido procesarlos primero.

Es posible que tenga que alternar entre estos dos.

No espere que esto sea fácil. Algunos programadores son demasiado buenos para molestarse con este tipo de trabajo sucio.Pero, puede estar gratamente sorprendido de lo rápido que puede hacer que todo funcione.

Answer 3

¿Tiene flexibilidad para desarrollar bajo Darwin (OSX) e implementar en Linux? Las herramientas de análisis de rendimiento son excelentes y fáciles de usar (Shark and Thread Viewer son útiles para su propósito).

Hay muchas herramientas de rendimiento de Linux, por supuesto. gprof, Valgrind (con Cachegrind, Callgrind, Massif) y Vtune harán lo que necesiten.

Que yo sepa, no hay ninguna herramienta que responda directamente sus preguntas. Sin embargo, las respuestas se pueden encontrar al hacer una referencia cruzada de los puntos de datos y las métricas de las soluciones basadas en la instrumentación y el muestreo.

Answer 4

Eche un vistazo a Intel VTune Amplifier XE (anteriormente ... Intel Thread Profiler) para ver si satisface sus necesidades. Esta y otras herramientas de desarrollo Intel Linux están disponibles free for non-commercial use.

En el video Using the Timeline in Intel VTune Amplifier XE se muestra una línea de tiempo de una aplicación de subprocesos múltiples. El presentador usa una pantalla gráfica para mostrar la actividad de bloqueo y cómo profundizar en la línea de origen del bloqueo particular que causa la serialización. A las 9:20, el presentador menciona "con la API marco puede marcar de manera programada ciertos eventos o fases en su código. Y estas marcas aparecerán en la línea de tiempo".