Felsöka flaskhalsar för prestanda
Om du kör ett HPC-program (högpresterande databehandling) på ett stort antal virtuella datorer (fler än 16) är det bäst att börja köra ett mindre problem på färre virtuella datorer. Det testet verifierar att HPC-programmet körs som förväntat.
Anta inte att bara för att du kör ett parallellt HPC-program fortsätter dess väggtid (förflutit i realtid) att minska när du kör det på fler virtuella datorer (med mer parallella processer). Faktum är att många nära kopplade HPC-program kan ha en längre väggtid när du försöker köra dem på andra virtuella datorer.
Den längre väggtiden kan inträffa av flera skäl. Till exempel:
Du kan implementera en parallell algoritm ineffektivt.
Problemstorleken, som är modellstorleken eller Antal frihetsgrader (NDOF), är inte tillräckligt stor. När programmet körs på mer parallella processer är mängden beräkning för varje process för liten. Därför dominerar kommunikationstiden mellan de parallella processerna den totala väggtiden. Den ökade kommunikationstiden ökar den totala väggtiden.
Det är viktigt att du vet hur bra ditt HPC-program skalar om problemstorleken som du är intresserad av. Sedan kan du avgöra vilken parallell effektivitet som är acceptabel ur prestanda- och kostnadssynpunkt.
Följande parallella snabbhetsformel mäter hur väl dina parallella programprestanda förbättras när du lägger till fler parallella processer:
$${\text{Parallel speed-up}} = {\dfrac{\text{Wall time (1 process)}}{\text{Wall time (n processes)}}}$$
Följande formel för parallell effektivitet visar hur effektivt du använder beräkningsresurser när du lägger till fler processer för att förbättra prestanda för parallella program:
$${\text{Parallel efficiency}} = {\dfrac{\text{Parallel speed-up}}{\text{N processes}}}$$
Om du är osäker på den parallella skalningsprestandan för ditt tätt kopplade HPC-program kör du en skalningsstudie. Kör med andra ord programmet på 1, 2, 4, 8, 16 och så vidare, parallella processer. Beräkna parallell hastighet och parallell effektivitet och bestäm sedan utifrån dessa resultat hur många parallella processer du vill använda.
Överväg att inaktivera onödiga tjänster som kan påverka parallell skalning, till exempel Azure Linux-agenten, innan du kör dina jobb. Du kan sedan återaktivera tjänsterna när dina jobb har slutförts. Den här rekommendationen gäller särskilt om du använder alla tillgängliga kärnor och skalar till ett stort antal virtuella datorer.
Om du vill stoppa Azure Linux-agenten använder du följande kommando:
sudo system stop waagent.service
Prestandakontroller
Följande information innehåller några grundläggande kontroller som hjälper dig att identifiera potentiella prestandaproblem.
Kontrollera att rätt antal processer och trådar körs på varje virtuell dator
Ett enkelt sätt att avgöra om du använder rätt antal processer och trådar på varje virtuell dator (VM) är att få systemets belastningsgenomsnitt på varje virtuell dator med ett verktyg som drifttid. Antalet ska vara ungefär lika med det totala förväntade antalet processer och trådar på varje virtuell dator. Om det registrerade belastningsgenomsnittet är lägre eller högre än det förväntade totala antalet processer och trådar indikerar det ett problem som måste åtgärdas.
Du bör noggrant kontrollera MPI-argumenten (message passing interface) och hur du anger antalet parallella trådar. Kontrollera till exempel programmets kommandoradsargument eller kontrollera värdena för miljövariabler som OMP_NUM_THREADS.
Kontrollera att processerna och trådarna är jämnt fördelade mellan alla NUMA-noddomäner
Om du använder det översta verktyget eller htop-verktyget kan du välja noddomänvyn Icke-enhetlig minnesåtkomst (NUMA) genom att 2 ange som en kommandoradsparameter. (Till exempel: på HB120_v2 bör du se 30 NUMA-noddomäner med hjälp av den här vyn.)
Procentandelen av användaranvändningen bör fördelas jämnt mellan alla NUMA-domäner. Om det inte är det kontrollerar du dina MPI-kommandoradsargument och miljövariabler.
Följande bild illustrerar utdata från det översta Linux-verktyget i NUMA-vyn. I det här fallet används varje NUMA till 50 procent.
Kontrollera körningstillståndet för processer och trådar
Om du vill kontrollera körningstillståndet för dina processer och trådar bör du använda top. Helst bör alla processer och trådar vara i ett körningstillstånd (R).
Om vissa eller alla dina processer och trådar är i ett avbrottsfritt viloläge (D) eller viloläge (S) undersöker du situationen för att förstå orsaken. Beroende på hur programmets algoritm är utformad kan det vara normalt och förväntat beteende för processer och trådar att vara i viloläge. Det kan dock tyda på en resursbegränsning, t.ex. otillräcklig I/O-prestanda på grund av den lagringslösning som du använder.
Följande formel visar hur effektivt ditt parallella program körs, om det väntar på vissa systemresurser (till exempel I/O) och i vilken utsträckning:
$${\text{Programväntetid}} = {\text{Wall time}} - \left( {\dfrac{\text{Total CPU-tid för alla parallella processer}}{\text{Antal parallella processer}}} \right)$$
Kontrollera om programmet är I/O-bundet
Processer och trådar som tillbringar en betydande tid i ett avbrottsfritt viloläge (D) eller viloläge (S) kan vara en indikator på att det finns en I/O-flaskhals som måste undersökas. Vissa HPC-program tillhandahåller prestandaprofilering som en del av sina utdata. Dessa profiler visar procentandelen tid som ägnas åt att utföra I/O- och läsa/skriva I/O-priser, vilket också kan peka på en I/O-flaskhals.
Om du är osäker på vart ditt I/O är på väg kan du använda verktyg som iostat för att hjälpa dig. Om du vill kontrollera om du har ett I/O-problem ändrar du lagringslösningen till något som du vet är snabbare än vad du har använt. Kör sedan HPC-programmet igen. Du kan till exempel använda en snabb lokal NVMe SSD- eller RAM-disk.
När du har ändrat den här ändringen ställer du dig följande frågor: Ser du någon förbättring av I/O-tiden? Har den totala väggtiden förbättrats? I så fall, med hur mycket?
Kontrollera om programmet är nätverksbundet
Fastställa procentandelen av den totala väggtiden som programmet ägnar åt att utföra processkommunikation (vilket vanligtvis är MPI-kommunikation).
Om ditt program är nätverksbundet kontrollerar du att du använder InfiniBand-nätverket när du kör ditt HPC-program. Om det finns en parallell hybridversion kan du avgöra om det minskar nätverkskommunikationstiden.
Om du har åtkomst till källkoden kontrollerar du om det finns effektivare sätt att implementera kommunikationen. Använd till exempel kollektiva åtgärder i stället för punkt-till-punkt eller prova att använda asynkron kommunikation i stället för synkron.