linux - teorico - tesis implementacion de una biblioteca virtual
Puestos de programa durante carreras largas (3)
Fijo:
Bueno, esto parece un poco tonto. Resulta que la parte superior no se mostraba correctamente y los programas continúan ejecutándose. Tal vez el tiempo de CPU se hizo demasiado grande para mostrar? De cualquier manera, el programa parece estar funcionando bien y toda esta pregunta era discutible.
Gracias (y perdón por la pregunta tonta).
Q original
Estoy ejecutando una simulación en una computadora con el servidor de Ubuntu 10.04.3. Las tiradas cortas (<24 horas) funcionan bien, pero las carreras largas finalmente se detienen. Por pérdida, me refiero a que el programa ya no tiene ningún tiempo de CPU, pero aún contiene toda la información en la memoria. Para ejecutar estas simulaciones, I SSH y desconecte el programa y canalice cualquier salida a un archivo.
Información Variada:
El sistema definitivamente no se está quedando sin RAM. El programa no necesita leer o escribir en el disco duro hasta que se complete; el cálculo se hace completamente en la memoria. El programa no se destruye, ya que todavía tiene un PID después de que se detiene. Estoy usando openmp, pero he aumentado la cantidad máxima de procesos y el tiempo máximo es ilimitado. Estoy encontrando los valores propios más grandes de una matriz usando la biblioteca ARPACK fortran.
¿Alguna idea sobre qué está causando este comportamiento o cómo reanudar mi programa actualmente estancado?
Gracias
Supongo que este es un programa OpenMP de tus etiquetas, aunque en realidad nunca dices esto. ¿ARPACK es seguro?
Parece que estás llegando a un punto muerto (más común en los programas MPI que OpenMP, pero definitivamente es posible). Lo primero que debe hacer es compilar indicadores de depuración, y la próxima vez que encuentre este problema, conéctelo con un depurador y descubra qué están haciendo los distintos subprocesos. Para gdb, por ejemplo, algunas instrucciones para cambiar entre hilos se muestran aquí .
La próxima vez que su programa "se detenga", adjunte GDB a él y thread apply all where .
- Si todos sus hilos están bloqueados esperando algún mutex, tiene un punto muerto.
- Si están esperando algo más (por ejemplo, leer), entonces necesita averiguar qué impide que se complete la operación.
Por lo general, en UNIX no necesita reconstruir con indicadores de depuración para obtener un seguimiento de pila significativo. No obtendrá números de archivo / línea, pero puede que no sean necesarios para diagnosticar el problema.
Una posible forma de entender qué está haciendo un programa en ejecución (es decir, un proceso) es adjuntarle un depurador con el gdb program *pid* (que funciona bien solo cuando el programa ha sido compilado con la depuración habilitada con -g ), o para usar strace en él, usando strace -p *pid* . strace comando strace es una utilidad (técnicamente, un depurador especializado construido sobre la interfaz de llamada del sistema ptrace ) que le muestra todas las llamadas al sistema realizadas por un programa o un proceso.
También hay una variante, llamada ltrace que intercepta la llamada a funciones en bibliotecas dinámicas.
Para tener una idea, prueba, por ejemplo, strace ls
Por supuesto, strace no te ayudará mucho si el programa en ejecución no está haciendo ninguna llamada al sistema.
Saludos. Basile Starynkevitch