De F26 a F30 completados, a escala real — ¿por qué es tan lento?

En F26 encapsulamos el entorno, en F27～F29 el orden del pipeline y en F30 el propio entorno de ejecución. Ahora llega el momento de ejecutar todo esto en un clúster HPC real con cientos o miles de muestras. Sin embargo, al ejecutarlo, es común que el tiempo total esté dominado no por el cálculo en sí, sino por el tiempo de espera en la cola de trabajos y la espera de E/S en el sistema de archivos compartido. En F31 abordamos estos dos cuellos de botella prácticos.

Principios — Las decisiones del programador de trabajos y las limitaciones del almacenamiento compartido

Slurm — El programador que empareja recursos con trabajos

Slurm (Simple Linux Utility for Resource Management) es un programador de trabajos que asigna los trabajos enviados en un clúster HPC compartido por múltiples usuarios, ajustándolos a los recursos disponibles (núcleos de CPU, memoria, GPU y tiempo). Los usuarios especifican los recursos necesarios mediante scripts sbatch para enviar los trabajos a la cola.

#!/bin/bash
#SBATCH --job-name=variant_call
#SBATCH --array=1-100          # Enviar 100 muestras como matriz de trabajos
#SBATCH --cpus-per-task=4
#SBATCH --mem=16G
#SBATCH --time=02:00:00
#SBATCH --output=logs/call_%A_%a.log

SAMPLE=$(sed -n "${SLURM_ARRAY_TASK_ID}p" sample_list.txt)

apptainer exec docker://broadinstitute/gatk:4.5.0.0 \
  gatk HaplotypeCaller -R ref/genome.fa -I aligned/${SAMPLE}.bam -O vcf/${SAMPLE}.vcf.gz

--array=1-100 es una matriz de trabajos (job array) que envía un mismo script como 100 instancias de trabajo independientes simultáneamente. Cada instancia puede saber en qué posición se encuentra mediante la variable de entorno SLURM_ARRAY_TASK_ID.

Retraso en la cola: un cuello de botella independiente del tiempo de cálculo

El momento en que se envía un trabajo al clúster no es necesariamente el instante en que comienza su ejecución. Los trabajos esperan en una cola junto con los de otros usuarios, y el programador determina el orden de ejecución según políticas de prioridad y distribución justa (fairshare).

$\text{Tiempo total} = \underbrace{\text{Tiempo de espera en cola}}_{\text{Difícil de controlar}} + \underbrace{\text{Tiempo real de cálculo}}_{\text{Objetivo de optimización}}$

Los trabajos que solicitan pocos recursos (por ejemplo, --cpus-per-task=1, --time=00:10:00) suelen comenzar antes porque el programador puede insertarlos fácilmente en huecos disponibles, mientras que los trabajos que solicitan muchos recursos durante mucho tiempo tienden a esperar más tiempo hasta que se libere la capacidad necesaria. El hábito de solicitar recursos con un margen excesivo respecto a lo realmente necesario es una causa frecuente de aumento del tiempo de espera en cola.

Ejemplo de cálculo manual: por qué el E/S del sistema de archivos compartido se convierte en cuello de botella

Supongamos que 100 trabajos leen simultáneamente desde un mismo sistema de archivos compartido (por ejemplo, Lustre) cada uno un archivo BAM de 5 GB. Si la capacidad total de procesamiento (throughput) del sistema de archivos es de 5 GB/s, el tiempo teóricamente necesario sería

$\frac{100 \times 5\text{GB}}{5\text{GB/s}} = 100\text{segundos}$

Sin embargo, este es un valor ideal que asume un uso perfecto del ancho de banda; en la práctica, cuando cientos de trabajos intentan accesos aleatorios (E/S aleatoria) simultáneamente, el servidor de metadatos del sistema de archivos suele convertirse en cuello de botella, haciendo que el proceso tome mucho más tiempo. Si el tiempo de cálculo por CPU de un trabajo individual es de 5 minutos pero la espera por E/S dura 15 minutos, el cuello de boteca real no es el cálculo sino el almacenamiento.

$\text{Cuello de botella percibido} = \max(\text{tiempo de CPU},\ \text{espera de E/S}) \quad \text{a menudo} \quad \text{espera de E/S} \gg \text{tiempo de CPU}$

Para mitigar este problema, una práctica común consiste en copiar previamente los archivos necesarios al disco local de caché (local scratch) de cada nodo al inicio del trabajo y realizar las lecturas y escrituras desde ese disco local, o bien reducir el número de trabajos y aumentar el tamaño de los lotes para disminuir la cantidad total de solicitudes al sistema de archivos.

Nube bajo demanda: una alternativa que cambia el patrón de espera

Si la cola HPC de la institución está constantemente saturada, otra alternativa es "explotar" (burst) las cargas de trabajo mediante recursos bajo demanda en la nube, como AWS Batch o Google Cloud Batch. Aunque permite iniciar nuevas instancias según sea necesario, la espera no desaparece por completo debido a las cuotas de cuenta, la disponibilidad de instancias, los repositorios de imágenes y la planificación. En cambio, se debe pagar exactamente por el tiempo utilizado.

$\text{HPC institucional}: \text{costo fijo, tiempo de espera variable} \qquad \text{nube bajo demanda}: \text{costo variable, cambio en el patrón de espera}$

Práctica: envío de matrices de trabajos y verificación del uso de recursos (simulación local)

# Si no se dispone de una cuenta real en un clúster Slurm, revisar solo la sintaxis y el flujo de los comandos.

# Enviar el trabajo
sbatch variant_call.sbatch

# Comprobar la cola — si hay muchos trabajos PENDING, puede existir un cuello de botella.
squeue -u $USER

# Comprobar el uso real de recursos de un trabajo terminado — usar seff si está instalado en el clúster
seff JOB_ID

# Si seff no está disponible, consultar los datos contables de Slurm
sacct -j JOB_ID --format=JobID,State,Elapsed,MaxRSS,AllocTRES

# Qué revisar en la salida: si Memory Efficiency es demasiado baja (por ejemplo, menos del 20 %),
# se puede reducir la solicitud --mem en futuros envíos para acortar la espera en la cola.

En clústeres con seff instalado, optimice la eficiencia de los recursos; en caso contrario, revise la información de contabilidad de sacct para ajustar de manera realista la solicitud de recursos de las tareas siguientes. El hábito de solicitar recursos en exceso no solo aumenta su tiempo de espera en la cola, sino que también reduce la utilización general de los recursos del clúster.

Mapeo CS

• Programación de trabajos (job scheduling): Las políticas de prioridad y asignación justa de Slurm son una extensión a escala de clúster de los algoritmos de programación de CPU aprendidos en cursos de sistemas operativos (colas de prioridad, programación justa).
• Teoría de colas (queueing theory): El análisis del tiempo de espera mediante la relación entre la tasa de llegada y la tasa de procesamiento de trabajos se basa en el marco estándar de la teoría de colas (como el modelo M/M/1).
• Cuello de botella de E/S y localidad de datos (data locality): La estrategia de reducir los cuellos de botella de E/S utilizando discos locales temporales en lugar de almacenamiento compartido sigue la misma lógica que el diseño de sistemas distribuidos que aprovechan la localidad de datos para reducir los costos de red (por ejemplo, la programación de localidad de datos de Hadoop).

Defectos frecuentes

• Configurar las solicitudes de recursos excesivamente por encima de lo necesario: La intención de mantener un margen amplio puede aumentar el tiempo de espera en la cola y disminuir la utilización general de los recursos del clúster. Es más seguro verificar el uso real con seff y ajustar gradualmente.
• Diagnosticar erróneamente un cuello de botella de E/S como uno de cálculo: Aumentar inmediatamente el número de núcleos de CPU cuando una tarea es lenta no resuelve el problema si el cuello de botella real está en la E/S. Es necesario desarrollar el hábito de diagnosticar separando los intervalos de cálculo y los de espera de E/S en los registros del tiempo de ejecución.

Para profundizar más

El texto principal ha sido reconstruido directamente por el equipo de investigación de BPD. Profundice consultando el artículo original y los materiales oficiales.

• Documentación oficial de Slurm: Referencia sobre sbatch, matrices de trabajos y sintaxis de solicitud de recursos.
• Formación de NCBI — Materiales prácticos de HPC: Contenido educativo oficial.
• Documentación oficial del sistema de archivos Lustre: Antecedentes de la arquitectura de E/S de sistemas de archivos paralelos.

Se han completado los cinco artículos sobre infraestructura práctica (F27～F31: Snakemake·Nextflow·nf-core·contenedores·HPC) dentro del subtema F2. Los restantes F32～F35 (PanVariants·agentes de IA·futuro de los Modelos Fundacionales·aprendizaje federado) continúan como el último conjunto "de futuro" de esta serie.