Debug dei colli di bottiglia delle prestazioni
Se si esegue un'applicazione HPC in un numero elevato di macchine virtuali (più di 16), è preferibile iniziare a eseguire un problema minore in un numero minore di macchine virtuali. Il test verifica che l'applicazione HPC venga eseguita come previsto.
Non presupporre che solo perché si sta eseguendo un'applicazione HPC parallela, il tempo totale di esecuzione (tempo reale trascorso) continui a diminuire mentre viene eseguita in più macchine virtuali (con più processi paralleli). In realtà, molte applicazioni HPC strettamente associate possono avere un tempo totale di esecuzione maggiore quando si tenta di eseguirle in altre VM.
Il tempo totale di esecuzione maggiore può verificarsi per diversi motivi. Ad esempio:
È possibile che sia stato implementato un algoritmo parallelo in modo non efficiente.
Le dimensioni del problema, ovvero le dimensioni del modello o il numero di gradi di libertà (NDOF), non sono sufficientemente grandi. Quando l'applicazione viene eseguita in più processi paralleli, la quantità di calcolo per ogni processo è troppo piccola. Di conseguenza, il tempo di comunicazione tra i processi paralleli domina il tempo totale di esecuzione. L'aumento del tempo di comunicazione aumenta il tempo totale di esecuzione.
È importante sapere in che modo l'applicazione HPC viene ridimensionata durante l'esecuzione delle dimensioni del problema a cui si è interessati. È quindi possibile determinare quale efficienza parallela è accettabile dal punto di vista delle prestazioni e dei costi.
La formula di accelerazione parallela seguente misura il miglioramento delle prestazioni delle applicazioni parallele quando si aggiungono più processi paralleli:
$${\text{Accelerazione parallela}} = {\dfrac{\text{Tempo totale di esecuzione (1 processo)}}{\text{Tempo totale di esecuzione (n processi)}}}$$
La formula dell'efficienza parallela seguente illustra quanto efficientemente si stanno usando le risorse di calcolo quando si aggiungono altri processi per migliorare le prestazioni delle applicazioni parallele:
$${\text{Efficienza parallela}} = {\dfrac{\text{Accelerazione parallela}}{\text{N processi}}}$$
Se non si è certi delle prestazioni di ridimensionamento parallele dell'applicazione HPC strettamente associata, eseguire uno studio di ridimensionamento. In altre parole, eseguire l'applicazione in 1, 2, 4, 8, 16 processi paralleli e così via. Calcolare l'accelerazione parallela e l'efficienza parallela, quindi decidere in base a questi risultati il numero di processi paralleli che si vuole usare.
Provare a disabilitare tutti i servizi non necessari che potrebbero avere un effetto sul ridimensionamento parallelo, ad esempio l'agente Linux di Azure, prima di eseguire i processi. È quindi possibile riabilitare i servizi al termine dei processi. Questa raccomandazione è particolarmente valida se si usano tutti i core disponibili e si esegue il ridimensionamento in un numero elevato di macchine virtuali.
Per arrestare l'agente Linux di Azure, usare il comando seguente:
sudo system stop waagent.service
Controlli delle prestazioni
Le informazioni seguenti forniscono alcuni controlli di base per identificare potenziali problemi di prestazioni.
Verificare che il numero corretto di processi e thread sia in esecuzione in ogni macchina virtuale
Un modo semplice per determinare se si sta usando il numero corretto di processi e thread in ogni macchina virtuale è ottenere la media del carico di sistema in ogni macchina virtuale con uno strumento come uptime. Il numero deve essere approssimativamente uguale al numero totale previsto di processi e thread in ogni macchina virtuale. Se la media del carico registrato è inferiore o superiore al numero totale previsto di processi e thread, è presente un problema che deve essere corretto.
È necessario controllare con attenzione gli argomenti MPI (Message Passing Interface) e il modo in cui si specifica il numero di thread paralleli. Ad esempio, controllare gli argomenti della riga di comando dell'applicazione o controllare i valori delle variabili di ambiente, ad esempio OMP_NUM_THREADS.
Verificare che i processi e i thread siano distribuiti uniformemente tra tutti i domini del nodo NUMA
Se si usa lo strumento top o htop, è possibile selezionare la visualizzazione del dominio del nodo NUMA (Nonuniform Memory Access) specificando 2 come parametro della riga di comando. Ad esempio, in HB120_v2 si dovrebbero vedere 30 domini del nodo NUMA usando questa visualizzazione.
La percentuale di uso degli utenti dovrebbe essere distribuita in modo uniforme tra tutti i domini NUMA. In caso contrario, controllare gli argomenti della riga di comando MPI e le variabili di ambiente.
L'immagine seguente illustra l'output dello strumento Linux top nella visualizzazione NUMA. In questo caso, ogni NUMA è usato al 50%.
Controllare lo stato di esecuzione di processi e thread
Per controllare lo stato di esecuzione dei processi e dei thread, è necessario usare top. Idealmente, tutti i processi e i thread devono trovarsi nello stato in esecuzione (R).
Se alcuni o tutti i processi e i thread si trovano in uno stato di sospensione (D) di continuità o sospensione (S), esaminare la situazione per comprendere il motivo. A seconda di come viene progettato l'algoritmo dell'applicazione, potrebbe essere un comportamento normale e previsto per i processi e i thread essere in stato di sospensione. Comunque questo potrebbe indicare un vincolo di risorse, ad esempio prestazioni di I/O insufficienti a causa della soluzione di archiviazione in uso.
La formula seguente indica l'efficienza dell'applicazione parallela in esecuzione, se è in attesa di alcune risorse di sistema, ad esempio I/O, e in quale misura:
$${\text{Tempo di attesa applicazione}} = {\text{Tempo totale di esecuzione}} - \left( {\dfrac{\text{Tempo CPU totale per tutti i processi paralleli}}{\text{Numero di processi paralleli}}} \right)$$
Verificare se l'applicazione è associata a I/O
I processi e i thread che trascorrono una notevole quantità di tempo in uno stato di sospensione di continuità (D) o sospensione (S) possono essere un indicatore della presenza di un collo di bottiglia di I/O che deve essere analizzato. Alcune applicazioni HPC forniscono la profilatura delle prestazioni come parte dell'output. Questi profili mostrano la percentuale di tempo impiegato per l'esecuzione di operazioni di I/O e di I/O in lettura/scrittura, che potrebbe indicare un collo di bottiglia di I/O.
In caso di dubbi sullo stato dell'I/O, è possibile usare strumenti come iostat. Per verificare se si ha un problema di I/O, modificare la soluzione di archiviazione con un elemento che si sa essere molto più veloce rispetto a quello in uso. Quindi eseguire di nuovo l'applicazione HPC. Ad esempio, è possibile usare un'unità SSD NVMe o un disco RAM locale veloce.
Dopo aver apportato questa modifica, porsi le domande seguenti: Si nota un miglioramento nel tempo di I/O? Il tempo totale di esecuzione complessivo è migliorato? Se sì, in quale percentuale?
Verificare se l'applicazione è associata alla rete
Determinare la percentuale di tempo totale di esecuzione che l'applicazione impiega per la comunicazione del processo, che in genere è la comunicazione MPI.
Se l'applicazione è associata alla rete, verificare che durante l'esecuzione dell'applicazione HPC sia in uso la rete InfiniBand. Se è disponibile una versione ibrida parallela, determinare se questo riduce il tempo di comunicazione di rete.
Se si ha accesso al codice sorgente, verificare se esistono modi più efficienti per implementare la comunicazione. Ad esempio, usare operazioni collettive anziché da punto a punto o provare a usare la comunicazione asincrona anziché sincrona.