Suorituskyvyn tarkistuslista
Tälle sivulle on koottu tärkeää tietoa, jonka avulla voit saavuttaa mahdollisimman hyvän suorituskyvyn ajoillesi ja järjestelmälle. Jos tiedät, miten ajon suorituskykyä voi parantaa, lisääthän oman panoksesi listaan!
Tarkista CPU-affiniteetti
CPU-affiniteetti kuvaa, miten käynnissä oleva ohjelma sijoitetaan supertietokonesolmun käytettävissä oleville CPU-ytimille. Suurteholaskennassa affiniteetin oikea asettaminen on tärkeää suorituskyvyn kannalta. Se auttaa ohjelmia hyödyntämään paremmin nopeita prosessorivälimuisteja ja muistia, vähentää tarpeetonta siirtymistä ytimien välillä ja johtaa vakaampiin ja ennustettavampiin ajoaikoihin.
Katso CPU-affiniteetin opas, josta löydät ohjeet ohjelmien CPU-affiniteetin tarkasteluun ja hallintaan.
Tee skaalautuvuustesti
On tärkeää varmistaa, että ajosi pystyy käyttämään tehokkaasti kaikkia sille varattuja resursseja (ytimiä). Tämä on varmistettava jokaiselle uudelle koodille ja ajotyypille (eri syöteaineisto) skaalautuvuustestillä. Täysiä solmuja käyttävät skaalautuvuustestit koskevat vain ajoja, joissa pyydetään täysiä solmuja.
Jos mahdollista, aja lyhyt simulointi kasvavalla määrällä resursseja (ytimiä) ja arvioi, kuinka paljon nopeammin ajosi valmistuu. Sen pitäisi nopeutua vähintään 1,5-kertaiseksi, kun kaksinkertaistat resurssit (ytimet). Älä varaa ajollesi enempää resursseja kuin se pystyy käyttämään tehokkaasti. Jos skaalautuvuustestit eivät ole käytännöllisiä, aja ensin työsi pienemmillä resursseilla ja kirjaa suorituskyky ylös. Kokeile lisätä resursseja ja varmista, että ajo (tai vastaava ajo) valmistuu nopeammin.
Huomaa, että kaikkia koodeja tai ajotyyppejä 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 vähentämiseksi:
- Käytä paikallista tallennustilaa erityisesti tekoälytyökuormille scratchin sijaan. Vain joissakin solmuissa on nopea paikallinen levy, mutta olemme nähneet 10-kertaisen suorituskyvyn parannuksen siirtymällä sen käyttöön. Tarkista suorituskykysi: älä käytä resurssia, jos siitä ei ole hyötyä. Esimerkki AI-eräajosta
- Selvitä, voitko valita, miten sovelluksesi tekee I/O:ta (esim. OpenFoam
voi käyttää collated-tiedostomuotoa), äläkä kirjoita levylle tarpeetonta tietoa
tai tee sitä liian usein (esim. GROMACSia
-v-lipulla ei pitäisi käyttää CSC:llä). - Yksi tapa välttää suuri määrä (pieniä) tiedostoja on asentaa monimutkainen Python- tai R-pohjainen ohjelmistosi singularity-konttiin. Tämä auttaa myös projapplin tiedostomääräkiintiöiden kanssa. Tarkempia 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.
Rajoita rinnakkaistehtä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:
jonotusjärjestelmä voi hajauttaa ne kymmenille solmuille (vain muutama ydin kuhunkin). Tämä on erittäin huonoa ajon suorituskyvyn kannalta ja aiheuttaa paljon (tarpeetonta) kommunikaatiota järjestelmän sisäverkossa. Jos rinnakkaisajojesi 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 ajojen jonotusaikoja.Paras suorituskyky (nopein kommunikaatio) saavutetaan pyytämällä täysiä solmuja:
Koska Puhti on tällä hetkellä pirstoutunut, täysien solmujen pyytäminen voi tarkoittaa pidempää jonotusaikaa, mutta tämä voi kompensoitua nopeammalla suorituksella. Jos tällä tavalla saadut jonotusajat tuntuvat kohtuuttomilta, voit silti rajoittaa enimmäismäärää solmuja, joille ajo voi hajautua. Esimerkiksi rajoittaaksesi 200 tehtävän ajon (joka mahtuu optimaalisesti 5 solmulle) enintään 10 solmuun, voit käyttää: Slurm varaa tällöin ajollesi 200 ydintä 5–10 solmusta.Kuinka monta solmua kannattaa sallia?
Jos täydet solmut tai vähimmäismäärä eivät sovi, on luultavasti parasta kokeilla ja seurata ajon suorituskykyä. Liian monen solmun valitseminen heikentää suorituskykyä enemmän kuin lyhyemmästä jonotuksesta saadaan hyötyä. Huomaa myös, että kokonaisuutena tämä on menetettyä laskentakapasiteettia.
Nyrkkisääntönä voisi ehkä olla, että ylärajaksi asetetaan 2 tai 3 kertaa se määrä, joka riittäisi kaikkien tehtävien sijoittamiseen. Hyvin suurissa rinnakkaisajoissa suositellaan vielä pienempää määrää, koska kommunikaatio lisääntyy ja todennäköisyys yhden hitaan solmun osumisesta varaukseen kasvaa, samoin kuin huonon kuormantasauksen todennäköisyys. Joka tapauksessa suuret rinnakkaisajot tulisi ajaa Mahdissa.