El rendimiento de la máquina disminuye con el tiempo hasta el reinicio

3

Tengo un pequeño problema con mis máquinas:

Con el tiempo, el rendimiento cae constantemente.

Estoy usando TensorFlow para entrenar una red neuronal utilizando la GPU. Mis datos son arrays float32 comprimidos xz que residen en una unidad de disco giratorio en una máquina y en un SSD en otra máquina. Hay unos 400.000 archivos de datos. Los archivos de datos se leen continuamente en subprocesos en segundo plano y se ponen en una cola, que puede tener una longitud máxima de 1000 elementos.

En el hilo de entrenamiento, los elementos se sacan de la cola y se pasan al entrenamiento en lotes de 200

Después de reiniciar, el rendimiento comienza con aproximadamente 4 segundos por lote. Después de varias horas de entrenamiento, el rendimiento cae a tan bajo como dieciséis segundos por lote.

He cronometrado la capacitación de manera algo detallada, y al principio es algo como:

  • 0.05s esperando a que se lean los datos de entrenamiento
  • 3.8s para procesar un lote en la GPU
  • 0.3s para escribir datos de resumen.

Después del entrenamiento, los tiempos son muy variables:

  • 0.5 y 4s para leer datos
  • 9 a 20 s para procesar un lote.
  • 0.3s para escribir datos de resumen

Cabe señalar que durante el procesamiento por lotes, supervisé la salida de nvidia-smi con un intervalo bastante alto y parece que la utilización de la GPU dura como máximo 1 segundo.

Este mal desempeño persiste en múltiples invocaciones del proceso de entrenamiento, y luego de cerrar sesión e iniciar sesión. Al reiniciar la máquina, los tiempos vuelven al original.

Desde esta pregunta, adquirí otra GPU (una GTX 1080) y configuré un sistema casi idéntico. La desaceleración también ocurre en la nueva máquina.

Cosas que probé

He comprobado el uso de la CPU, y como máximo se utiliza 1 CPU, y siempre se utiliza al 100%, la mayoría de las veces es la utilización de subprocesos del núcleo.

He comprobado el uso de la memoria, y es de 10 GB (de 11 GB). Esto es un poco ajustado, pero el sistema no inicia el intercambio (el intercambio se mantiene en 30MB).

He comprobado el uso del disco y, aparte de mi código que lee los datos, parece que no hay nada extraño en marcha.

He comprobado la temperatura de la GPU con nvidia-smi, y siempre se mantiene por debajo de 60 ° C.

He comprobado la temperatura de la CPU y de la placa base, y siempre se mantienen por debajo de 65 ° C.

Me estoy quedando sin ideas cuál podría ser el problema. ¿Algunas ideas?

Especificaciones

Sistema 1:

  • Intel (R) Core (TM) i7 930 a 2.80 GHz, 4 núcleos con Hyperthreading
  • 11 GB de RAM
  • NVIDIA GeForce GTX 960 con 4 GB VRAM
  • Ubuntu 16.04.1 LTS Server, arquitectura amd64
  • Controlador NVIDIA propietario, versión 361.42
  • Versión del kernel 4.4.0-31-genérico
  • Python 3.5.2
  • TensorFlow 0.9.0

Sistema 2:

  • Intel (R) Core (TM) i7 930 a 2.80 GHz, 4 núcleos con Hyperthreading
  • 11 GB de RAM
  • NVIDIA GeForce GTX 1080 con 8 GB VRAM
  • Ubuntu 16.04.1 LTS Server, arquitectura amd64
  • Controlador NVIDIA propietario, versión 367.35
  • Versión del kernel 4.4.0-31-genérico
  • Python 3.5.2
  • TensorFlow 0.9.0

Actualizar

Después de algunas pruebas más, parece que la lentitud es volátil. A veces, los lotes se procesan 10 veces más lento que en el mejor de los casos, pero luego vuelven a la normalidad nuevamente. 

I performed an strace on the process. The summary is this:
strace: Process 7351 attached
strace: Process 7351 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 95.40    0.674470         437      1545       126 futex
  4.37    0.030860        2572        12           munmap
  0.23    0.001627         814         2           madvise
  0.00    0.000000           0        13           write
  0.00    0.000000           0        10           mmap
  0.00    0.000000           0         1           access
------ ----------- ----------- --------- --------- ----------------
100.00    0.706957                  1583       126 total

Esto, sin embargo, parece muy similar cuando todo parece funcionar normalmente. En detalle, he subido un archivo strace aquí:

https://drive.google.com/open?id=0B8TdHRNT7E-0X3F4eF9xWlRsb2s

Por lo que sé, casi todas esas llamadas son llamadas futex. No estoy muy seguro de qué aprender de eso.

ubuntu python nvidia-graphics-card gpu fat-lobyte
fuente
Supongo que deberías buscar / perfil, encontrar la función de cuello de botella y volver aquí con los resultados. Otra opción: reiniciar los servicios uno por uno, reinicializar el dispositivo gpu
Posible duplicado de ¿Cómo puedes hacer un perfil de un script de Python?
ivan_pozdeev
La degradación con el tiempo se siente como una pérdida de memoria. Once gigabytes de RAM se sienten como una configuración de hardware extraña. Puede valer la pena el tiempo para probar con una combinación más típica de tarjetas de memoria. Pero con la advertencia de que solo voy por sentir.
ben rudgers
@benrudgers: El diseño de la memoria es 6 veces 2048 MB sticks, que de alguna manera agregan hasta 11GB en Linux-land. No creo que esto sea una pérdida de memoria, porque el uso de la memoria del sistema se mantiene bajo. Además, ¿por qué persistirían las pérdidas de memoria después de que todos los procesos hayan muerto?
fat-lobyte
Hay datos que fluyen dentro y fuera de la GPU y se controlan a nivel de kernel. Un error en el controlador podría explicarlo. De todos modos, podría valer la pena correr sudo dmidecode --type memory Para ver si hay algo malo con la memoria RAM. Probablemente también valga la pena probar un controlador de GPU diferente, es decir, cambiar de la fuente abierta a la propietaria o viceversa o ejecutar la última versión de launchpad. Siempre se puede presentar un error en Github.
ben rudgers

Respuestas:

1

Por ahora, mi problema parece haber sido mitigado.

He hecho esto instalando el libgoogle-perftools-dev paquete, y comenzar cada ejecución individual con:

LD_PRELOAD="/usr/lib/libmalloc.so"

Esto ha garantizado un rendimiento mucho más estable y desde entonces no he tenido una desaceleración única

Entonces, aparentemente, el asignador GLIBC está teniendo dificultades para recolectar basura durante períodos prolongados.

En cuanto a por qué mi problema parecía persistir a través de las invocaciones: no lo sé. Existe una cierta posibilidad, que malinterpreté mis resultados y que los procesos se ralentizaron independientemente unos de otros.

De cualquier manera, ejecutar mi código durante más de una semana con el nuevo asignador y no tener una sola ralentización, llamaría resuelto este problema.

fat-lobyte
fuente