Grid Engine Config Consejos

Hay una cosa que siempre tenemos que ver con un nuevo clúster de cálculo, y que es permitir que los límites de memoria de disco. Los usuarios por lo general no son demasiado interesado en ningún tipo de límite, porque los trabajos finalmente encontrarse con ellos. Una vez que la realización se hace que los límites se asegura la estabilidad de nodo y el tiempo de actividad, los usuarios demandarán ellos. Sin límites, un mal trabajo puede fallar un nodo y derribar muchos otros trabajos.

Para activar límites de memoria de disco, modificamos la configuración compleja para hacer h_vmem solicitable.

 # qconf-mc 
 h_vmem h_vmem MEMORIA <= SI SI 1g 0 

Una vez que el complejo está dentro, es una buena idea para definir una opción por defecto para qsub en el sge_request file $ SGE_ROOT / default / common /. Al habilitar h_vmem, también hay que establecer un valor predeterminado para h_stack. h_vmem establece un límite en la memoria virtual, mientras h_stack establece un límite en el espacio de pila para la ejecución binario. Sin un valor suficiente para h_stack, programas como Python, Matlab o IDL no se podrán iniciar. Aquí, también estamos atando cada trabajo a un solo núcleo. lineal

 vinculante: 1 
-q all.q 
-l h_vmem = 1g 
-l h_stack = 128m 

Si queremos establecer manualmente valores para cada nodo individual, como las franjas horarias y la memoria, un for-loop es muy útil.

 # qconf-rattr execHost complex_values ​​ranuras = 8, num_proc = 8, h_vmem = 8g node01 
 # for ((I = 1; I <= 16; I + +)); no 
 > NODO = `printf" nodo% 02d  n "$  I` 
> MEM = `ssh $  NODE 'free-b | grep Souvenirs | cut-d" "-f 5'` 
> SWAP = `ssh $  NODE 'free-b | Intercambio grep | cut-d" "-f 4'` 
> Vmem = `echo $  MEM + $  SWAP | bc` 
> qconf rattr-execHost complex_values ​​ranuras = 8, num_proc = 8, h_vmem = $  VMEM $  NODO 
> hecho 

Para enviar un trabajo con un límite de 4 GB, utilice la opción de línea de comandos-l.

 $  qsub-l h_vmem = 4g-l h_stack = 256m myjob.sh 

Para ver la memoria disponible, use qstat.

 $  qstat-F h_vmem 

También es una buena idea para poner límites a la cantidad de memoria cualquier proceso único en el nodo de inicio de sesión puede atribuir, de los / etc / security / limits . conf file. En este ejemplo se limitará cualquier usuario en las clusterusers del grupo a 4 gigas por proceso. Cualquier cosa más grande debe ser corrió a través qlogin. Al añadir nuevos usuarios, asegúrese de añadirlas a este grupo ahora por defecto.

 cualquier proceso de 4 GB = 1024 * 1024 * 4KB = 4194304 
 @ clusterusers duro rss 4194304 
 @ clusterusers duro como 4194304 

No debería ser también un límite en la muchos puestos de trabajo de un solo usuario puede hacer cola a la vez. Si un usuario debe presentar más de 2.000 puestos de trabajo al mismo tiempo, es posible que desee considerar un flujo de trabajo más manejable utilizando los trabajos de arreglo.

 # qconf-MCONF 
 max_u_jobs 2000 

Si queremos limitar el número de puestos de trabajo de un solo usuario puede tener en el estado de ejecución de forma simultánea:

 # qconf-msconf 
 
 max_reservation 128 maxujobs 128 

Si la cola estará aceptando de ranuras múltiples trabajos paralelos, reserva de turnos debería activarse para evitar el hambre. De lo contrario, el empleo de una sola ranura serán constantemente rellenar el espacio por delante del gran trabajo. . Esto se puede hacer mediante la presentación de trabajos de varias tragaperras con la opción "-R y"

Para habilitar una política FairShare simple entre todos los usuarios, sólo hay tres opciones para comprobar:

 # qconf-MCONF 
 enforce_user auto 
 
 auto_user_fshare 100 # qconf-msconf 
 weight_tickets_functional 10000 

Para ser un poco más detallado, debemos recoger algo de información planificador de tareas. # man sched_conf
# qconf-msconf
schedd_job_info true Ahora podemos ver por qué o por qué no se programa un trabajo.

 $  qstat-j 427997 
 $  qacct-j 427 997 

Si tenemos la intención de permitir que los programas gráficos GUI en la cola, se debe configurar un script de envoltorio qlogin con el reenvío de X11 adecuada.

 # vim / usr / global / sge / qlogin_wrapper 
 # chmod + x / usr / global / sge / qlogin_wrapper 

qlogin_wrapper:

 # / bin / sh 
 HOST = $  1 
 PORT = $  2 
 
 turno turno 
 echo / usr / bin / ssh-Y-p $  PUERTO $  HOST 
 / usr / bin / ssh-Y-p $  PUERTO $  HOST 

Establecer la envoltura y ssh shell qlogin:

 # qconf-MCONF 
 qlogin_command / usr / local / sge / qlogin_wrapper 
 mundial qlogin_daemon / usr / sbin / sshd-i 

Si disponer de un servidor de licencias flotantes con un número limitado de asientos, vamos a querer configurar un recurso complejo consumible. Cuando un usuario envía un trabajo, la opción qsub ‘-l idl = 1’ debe ser utilizado. En este ejemplo, el número de puestos de trabajo que especifican idl se limitarán a 15 en un momento dado.

 # qconf-mc 
 matlab ml INT <= SI SI 0 0 
 idl idl INT <= SI SI 0 0 
 # qconf-me 
 mundial complex_values ​​matlab = 10, idl = 15 

Si queremos tener múltiples colas a través de los mismos anfitriones, podemos definir una política para que los nodos no se conviertan en un exceso de solicitudes.

 # qconf-arqs /> 
 nombre limit_slots_to_cores_rqs 
 Descripción Evita sobresuscripción núcleo a través de colas. 
 permitido verdadero límite /> 
} 

Estos son algunos alias prácticos que encuentro útil en mi ~ / bashrc:.

 alias qconf-all = 'qconf-mq all.q' 
 alias qconf-offline = 'echo "all.q @ nodeXX";  ranuras de cola qconf-rattr 0' # all.q @ node23 
 alias qconf-online echo = '"all.q @ nodeXX";  qconf -rattr ranuras de cola de 8 '# all.q @ node23 
 alias qstat-errors ='  qstat-f-explicar E '
 alias qstat-summary ='  qstat-g c '
 alias qstat-mem = 'qstat-F h_vmem' alias /> 
 alias qstat-io = 'qstat-ext | awk' "'"' {print $  11 " "$  5" "$  1} '"' "'| grep-v"  -  - "| sort-n' 
 alias QMOD-clear = ' QMOD-c" * "' 

Y hecho. Si usted tiene algunos deben-hacer los pasos de configuración, por favor, publicarlo en los comentarios a continuación.