2011/9/22 Alberto Bertogli <[email protected]>: > On Thu, Sep 22, 2011 at 09:20:38PM +0200, Damian Montaldo wrote: >> > En el caso normal, solo hay que esperar un poquito que termine la >> > operacion de I/O que los tiene bloqueados y ya, no es que una vez que >> > entran en D ya no salen mas, eso es anormal. >> >> Ahora desde afuera no puedo entrar para ver la fecha pero era más de >> un mes seguro :P >> Esto me llevó a armar un script que se fija en todos los nodos de >> cómputo a ver si tienen procesos "D" haciendo IO y se fija la fecha >> para ver si colgaron porque suele pasar que el sistema de colas no los >> puede desalojar y hay veces que hasta se quedan morfando ram o swap. > > Si, los procesos en este estado para el kernel siguen bien porque es > "normal" que esten en D, entonces si te van a ocupar memoria, swap, > tener los file descriptors abiertos y toda la bola de un proceso comun y > corriente que esta activo. Lo que si, no van a usar CPU porque estan > esperando a que el kernel les devuelva los datos de I/O (que en tu caso > es claro que nunca llegan probablemente por algun bug en el filesystem > distribuido).
Si, pero se caen los nodos por (ab)uso de ram :P > Hay una opcion del kernel que pone un "watchdog" interno y emite > bastante informacion cuando encuentra un proceso en D por mas de dos > minutos o un tiempo por el estilo; si vas a debuggear o hacer un bug > report a ver que le esta pasando al filesystem capaz te es util. Por las características de los trabajos que se ponen a ejecutar los usuarios (digamos que secuenciamientos de cadenas de ADN con mucho IO de por medio) es común que estén todo el día haciendo IO esos procesos, practicamente todo lo que duren sus jobs hasta que los desalojen las colas. Con lo cual solo 2 min en estado D sería todo un milagro :P > Suerte! =) > Alberto Gracias. _______________________________________________ Glug mailing list [email protected] http://glugcen.dc.uba.ar/cgi-bin/mailman/listinfo/glug
