Suorituskyvyn tarkistuslista

Tälle sivulle on koottu tärkeää tietoa, jonka avulla voit saavuttaa mahdollisimman hyvän suorituskyvyn töillesi ja järjestelmälle. Jos tiedät, miten työn suorituskykyä voi parantaa, lisääthän tietosi listaan!

Rajoita rinnakkaisten tehtävien tarpeetonta hajauttamista Puhdissa

Yksi vahvan skaalautuvuuden rajoittavista tekijöistä on tehtävien välinen kommunikaatio. Kommunikaatio solmun sisällä on nopeampaa kuin solmujen välillä. On optimaalista käyttää mahdollisimman vähän solmuja.

Jos resursseja pyydetään yksinkertaisesti näin:

#SBATCH --ntasks=200

jonotusjärjestelmä voi hajauttaa ne kymmenille solmuille (vain muutama ydin kuhunkin). Tämä on erittäin huono työn suorituskyvyn kannalta ja aiheuttaa paljon (tarpeetonta) kommunikaatiota järjestelmän sisäisessä verkossa. Jos rinnakkaisten töidesi suorituskyky on heikentynyt, tämä voi olla syynä. Yleisesti ottaen tätä tulisi välttää. Tämä myös pirstoo järjestelmää ja kasvattaa suurten töiden jonotusaikoja.

Paras suorituskyky (nopein kommunikaatio) saavutetaan pyytämällä kokonaisia solmuja:

#SBATCH --nodes=5
#SBATCH --ntasks-per-node=40

Koska Puhti on tällä hetkellä pirstoutunut, kokonaisten solmujen pyytäminen voi tarkoittaa pidempää jonotusaikaa, mutta tämä voi kompensoitua nopeampana suorituksena. Jos tällaiset jonotusajat tuntuvat kohtuuttomilta, voit silti rajoittaa niiden solmujen enimmäismäärää, joille työ voi hajautua. Esimerkiksi rajoittaaksesi 200 tehtävän työn (joka mahtuu optimaalisesti 5 solmulle) enintään 10 solmuun, voit käyttää:

#SBATCH --ntasks=200
#SBATCH --nodes=5-10

Slurm varaa tällöin työllesi 200 ydintä 5–10 solmusta.

Kuinka monta solmua kannattaa sallia?

Jos kokonaiset solmut tai vähimmäismäärä eivät sovi, on luultavasti parasta kokeilla ja seurata työn suorituskykyä. Liian monen solmun valitseminen heikentää suorituskykyä enemmän kuin lyhyemmästä jonotusajasta saadaan hyötyä. Huomaa myös, että kokonaisuutena tämä on menetettyä laskentakapasiteettia.

Ehkä nyrkkisääntönä voisi olla asettaa yläraja 2 tai 3 kertaan siitä määrästä, joka riittäisi kaikille tehtäville. Hyvin suurissa rinnakkaisissa töissä suositellaan jopa pienempää määrää, koska kommunikaation määrä kasvaa, samoin todennäköisyys sille, että varauksessa on yksi hidas solmu, ja huonon kuormantasauksen riski kasvaa. Joka tapauksessa suuret rinnakkaiset työt tulisi ajaa Mahdissa.

Hybridirinnakkaistaminen Mahdissa

Monet HPC-sovellukset hyötyvät OpenMP-säikeiden sitomisesta CPU-ytimiin. Tämä voidaan tehdä asettamalla export OMP_PLACES=cores eräajon komentosarjassa.

Kun käynnistät uusia tuotantoajoja, on myös hyvä käytäntö varmistaa oikea säieaffiniteetti lisäämällä eräajon komentosarjaan

export OMP_AFFINITY_FORMAT="Process %P level %L thread %0.3n affinity %A"
export OMP_DISPLAY_AFFINITY=true

Ajonaikainen affiniteetti tulostetaan eräajon vakiovirheeseen. Jos tuloste osoittaa, että useita prosesseja/säikeitä on sidottu samaan ytimeen, eli

Process 164433 level 1 thread 000 affinity 0
Process 164433 level 1 thread 001 affinity 0

suorituskyky voi heikentyä, ja asetukset kannattaa tarkistaa eräajon komentosarjasta.

Tee skaalaustesti

On tärkeää varmistaa, että työsi pystyy käyttämään tehokkaasti kaikkia varattuja resursseja (ytimiä). Tämä täytyy varmistaa jokaiselle uudelle koodille ja työtyypille (eri syöte) skaalaustestillä. Täysiä solmuja käyttävät skaalaustestit soveltuvat vain töille, jotka pyytävät kokonaisia solmuja.

Jos mahdollista, aja lyhyt simulointi kasvavalla määrällä resursseja (ytimiä) ja arvioi, kuinka paljon nopeammin työsi valmistuu. Sen pitäisi nopeutua vähintään 1,5-kertaisesti, kun kaksinkertaistat resurssit (ytimet). Älä varaa työllesi enempää resursseja kuin se pystyy käyttämään tehokkaasti. Jos skaalaustestit eivät ole käytännöllisiä, aja työsi ensin pienemmillä resursseilla ja kirjaa suorituskyky ylös. Kokeile lisätä resursseja ja varmista, että työ (tai vastaava työ) valmistuu nopeammin.

Huomaa, että kaikkia koodeja tai työtyyppejä ei voi ajaa rinnakkain. Varmista tämä ensin omalle koodillesi.

Huomioi I/O – sillä voi olla suuri vaikutus

Jos työkuormasi kirjoittaa tai lukee suuren määrän pieniä tiedostoja, saatat havaita heikon I/O-suorituskyvyn, vaikka kokonaismäärä ei olisi kovin suuri. Ota huomioon seuraavat asiat mahdollisten pullonkaulojen lieventämiseksi:

Käytä paikallista tallennustilaa erityisesti AI-työkuormille scratchin sijaan. Vain joissakin solmuissa on nopea paikallinen levy, mutta olemme nähneet 10-kertaisen suorituskyvyn paranemisen siirtymällä sen käyttöön. Tarkista suorituskykysi: älä käytä resurssia, jos siitä ei ole hyötyä. AI-eräajoesimerkki
Selvitä, voitko valita, miten sovelluksesi tekee I/O:ta (esim. OpenFoam voi käyttää collated-tiedostomuotoa), äläkä kirjoita tarpeetonta tietoa levylle tai tee sitä liian usein (esim. GROMACSia -v-lipulla ei pitäisi käyttää CSC:llä).
Yksi tapa välttää suuren (pienten) tiedostojen määrän syntyminen on asentaa monimutkainen Python- tai R-pohjainen ohjelmistosi singularity-konttiin. Tämä auttaa myös projapplin tiedostomääräkiintiöiden kanssa. Yksityiskohtaisia esimerkkejä tämän tekemisestä kirjoitetaan parhaillaan.

Sovelluksille, jotka kirjoittavat ja lukevat suuria tiedostoja, I/O-suorituskykyä voidaan usein parantaa oikeilla Lustre-asetuksilla:

Jos sovelluksesi tekee rinnakkaista I/O:ta, aseta sopiva stripe count komennolla lfs setstripe -c, lisätietoja kohdassa Lustren parhaat käytännöt.
Käytä kollektiivista rinnakkaista I/O:ta, jos mahdollista.
Katso myös laajemmat I/O-optimointivinkit.