Slik optimaliserer du Linux-minnestatistikk med NVIDIA GPU-er

Informatec Digital » Ressurser » Slik optimaliserer du Linux-minnestatistikk med NVIDIA GPU-er

Hvis du jobber med NVIDIA GPU-er på Linux, må du før eller siden forstå hva som skjer med systemets minne, ytelse og interne statistikk . Enten det er for spilling, maskinlæring, vitenskapelige simuleringer eller et datasenter, utgjør overvåking av disse dataene forskjellen mellom en maskin som bare "fungerer" og en virkelig optimalisert plattform.

Samtidig kommer mange brukere til Linux med forventning om bedre ytelse enn på Windows med NVIDIA GPU-en sin , men støter så på benchmark-tester som ikke alltid viser de forventede resultatene. Nøkkelen ligger i å vite hvordan man overvåker, tolker og finjusterer både operativsystemet og GPU-konfigurasjonen, ved å utnytte spesifikke verktøy som DCGM, dcgm-exporter, gpu-monitoring-tools og observasjonsløsninger som Elastic.

NVIDIA GPU-ytelse på Linux: forventninger og virkelighet

Når noen med et moderne grafikkort, som et RTX 4070 eller et annet avansert GPU , vurderer å bytte til Linux, er det veldig vanlig at de undersøker på forum, Reddit, YouTube-videoer og alle slags guider. I årevis har ideen om at Linux alltid yter bedre enn Windows blitt gjentatt, men realiteten, når man ser på seriøse benchmarks og sammenlignende tester , er mye mer nyansert.

Innen spilling har Linux blitt betydelig forbedret takket være Steam, Proton og DXVK , som lar de fleste Windows-titler kjøre på denne plattformen. Når man ser på resultater i krevende spill, oppnås imidlertid ikke alltid de samme FPS-nivåene som på Windows, spesielt når spillet mangler en native versjon og er avhengig av kompatibilitetslag.

Utenom spilling har NVIDIA GPU-er blitt grunnlaget for høyytelsesinfrastruktur : trening av nevrale nettverk, komplekse fysikksimuleringer, rendering og massive arbeidsbelastninger i datasentre. I denne sammenhengen er det avgjørende å overvåke minnebruken i Linux og maksimere ytelsen til NVIDIA GPU-en, og det er der et godt overvåkingssystem utgjør hele forskjellen.

Det er også viktig å huske på at ytelsen på Linux ikke bare avhenger av selve GPU-en, men av kombinasjonen av NVIDIAs proprietære drivere, kjernen, den valgte distribusjonen og kortets strøm- og klokkeinnstillinger. Hvis noen av disse elementene er feiljustert, kan referansetester vise skuffende resultater selv med svært kraftig maskinvare.

Hvorfor er GPU-overvåking så viktig i Linux?

NVIDIA GPU-er er ikke lenger bare «spillkort»; de har blitt en sentral komponent i datasentre, offentlige skyer og dataintensive miljøer . I mange implementeringer kommer mesteparten av datakraften fra GPU-en i stedet for CPU-en, så å ignorere ytelsesmålingene er rett og slett en luksus som verken bedrifter eller avanserte brukere har råd til.

I slike tilfeller er det ikke nok å vite hvor mye minne du har totalt eller hvilken GPU-modell som er installert. Det er viktig å kunne se minnebruk, GPU-belastning, temperatur, strømforbruk , klokkehastigheter og andre interne tellere i sanntid som gir ledetråder om flaskehalser eller stabilitetsproblemer.

Videre er Linux det dominerende operativsystemet i databehandlingsklynger, HPC og skybaserte AI-plattformer , så hele overvåkingsinfrastrukturen dreier seg vanligvis rundt det. NVIDIA tilbyr sin egen stakk for å eksponere målinger, og løsninger som Elastic Observability muliggjør sentralisering av disse dataene, visualisering av dem og generering av intelligente varsler på en svært fleksibel måte.

Hvis du bruker NVIDIA GPU-er med leverandører som Google Cloud, AWS eller Genesis Cloud , hjelper overvåking deg ikke bare med å oppdage feil; det hjelper deg også med å bekrefte at det du betaler for i skyen brukes effektivt, slik at du unngår unødvendige kostnader fra underutnyttede eller feilkonfigurerte instanser.

Et annet viktig poeng er at mange GPU-målinger, i motsetning til CPU-målinger, ikke er like godt integrert i standard Linux-verktøy. Derfor er komponenter som NVIDIA Datacenter GPU Manager (DCGM) og dedikerte metrikk-eksportører som integreres med moderne observasjonssystemer spesielt nyttige.

Grunnleggende avhengigheter: NVIDIA-drivere, DCGM og overvåkingsverktøy

For å få optimalisert Linux-minnestatistikk på NVIDIA, er det første trinnet å ha et godt konfigurert miljø: de riktige driverne, GPU-verktøyene og en observerbarhetsløsning for å samle inn og visualisere dataene. Det er meningsløst å ha pene grafer hvis systemet ikke kan vise beregningene konsekvent.

I datasentermiljøer tilbyr NVIDIA Datacenter GPU Manager (DCGM) , som fungerer som grunnlag for å samle inn et bredt spekter av målinger, fra minnebruk og temperatur til detaljert intern ytelsesinformasjon. Installasjonen er vanligvis avhengig av pakker for populære distribusjoner som Ubuntu 18.04 og andre kompatible versjoner.

Under oppsettprosessen beskrevet av NVIDIA er det viktig å være oppmerksom på detaljer som parameteren i CUDA-repositorierFor typiske 64-bits systemer, resultatet av kommandoen uname -a viser at arkitektur er x86_64Derfor må linjene som legges til i pakkesystemet bruke den verdien riktig.

Et typisk eksempel på å legge til CUDA-depotet i en Debian/Ubuntu-basert distro ville være noe slikt:
echo "deb http://developer.download.nvidia.com/compute/cuda/repos/$distribution/x86_64 /" | sudo tee /etc/apt/sources.list.d/cuda.list

Det er også lurt å sjekke om dokumentasjonen har noen skrivefeil i offisielle kommandoer, for eksempel å bruke et ekstra >-symbol når man definerer variabelen $distribution på linjen der GPG-nøklene importeres, som må korrigeres før kjøring:

sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/$distribution/x86_64/7fa2af80.pub

Når driverne og DCGM er installert, kan vi sjekke den grunnleggende statusen til GPU-en med standardverktøyet nvidia-smi , som viser modellen, totalt og brukt minne, temperatur og prosesser som bruker kortet for øyeblikket.

Installering av gpu-monitoring-tools og dcgm-exporter

For å integrere Linux-minne og NVIDIA GPU-statistikk med eksterne systemer som Prometheus eller Elastic, tilbyr NVIDIA gpu-monitoring-tools , som inkluderer dcgm-exporter-komponenten. Disse verktøyene distribueres som Go-kildekode, så du må ha Go installert og riktig konfigurert på systemet ditt.

I et typisk scenario lastes Go ned og installeres på /usr/localPakk ut tar.gz-filen og legg til Go-binærfilen i PATH-filen din. Klon deretter det offisielle arkivet:
cd /tmp
git clone https://github.com/NVIDIA/gpu-monitoring-tools.git
cd gpu-monitoring-tools/
sudo env "PATH=$PATH:/usr/local/go/bin" make install

Hovedkomponenten i denne pakken er dcgm-eksportørDenne komponenten eksponerer DCGM-målinger i et format Prometheus kan forstå. Når den startes, starter den en HTTP-server som som standard lytter på en lokal adresse, for eksempel localhost:9090 og tilbyr alle tilgjengelige målinger.

Konfigurasjonen av hvilken statistikk som skal vises er definert i filen /etc/dcgm-exporter/default-counters.csv , som inneholder dusinvis av forhåndsdefinerte tellere. Disse inkluderer målinger relatert til GPU-minne, temperatur, strømforbruk og diverse interne ytelsesindikatorer . For mer detaljert kontroll beskriver dokumentasjonen for DCGM Library API den komplette listen over målinger som kan aktiveres.

Når du starter dcgm-exporter med en kommando som denne:
dcgm-exporter --address localhost:9090
Du vil se initialiseringsmeldinger som indikerer at DCGM har startet. Det er vanlig å motta advarsler om at visse moduler ikke lastes inn, for eksempel DCP-målinger, som i denne sammenhengen kan å bli ignorert uten særlig problemer hvis de ikke blir brukt.

Integrasjon med elastisk observerbarhet ved bruk av Metricbeat

Når NVIDIA GPU-målinger er eksponert via dcgm-exporter, er det neste logiske trinnet å sende disse dataene til en observasjonsplattform . Et kraftig alternativ er Elastic Observability, som bruker komponenter som Metricbeat til å samle inn målinger og sentralisere dem i en Elastic Cloud-distribusjon eller en selvadministrert stakk.

For å gjøre dette, installeres det først Metricbeat på Linux-systemet der dcgm-exporter kjører. Last ned .deb-pakken som tilsvarer den nyeste versjonen, og installer den med dpkg -i og hovedfilen er konfigurert /etc/metricbeat/metricbeat.yml slik at den peker til Elastic Cloud-distribusjonen ved hjelp av parameterne cloud.id y cloud.auth.

Verdien av cloud.id Den har vanligvis en kodet form som identifiserer regionen og den elastiske utplasseringen, mens cloud.auth Kombiner brukernavn og passord, for eksempel:
cloud.id: "staging:dXMtY2VudHJhbDEuZ2NwLmNsb3VkLmVzLmlvJDM4ODZkYmUwMWNjODQ2NDM4YjRlNzg5OWEyZDAwNGM5JDBiMTc0YzYyMTVlYTQwYWQ5M2NmMGY4MjVhNzJmOGRk"
cloud.auth: "elastic:J7KYiDku2wP7DFr62zV4zL4y"
(i et reelt miljø vil brukerens egne sikre påloggingsinformasjon selvsagt bli brukt).

Metricbeats innganger er modulære, og i dette tilfellet må vi aktivere Prometheus-modulenfordi dcgm-exporter publiserer sine målinger i det formatet. Aktivering gjøres med:
sudo metricbeat modules enable prometheus

Før alt settes i drift, anbefales det å kjøre noen konfigurasjonstester for å sikre at Metricbeat er riktig konfigurert og kan koble til Elastic Cloud og Prometheus-endepunktet. Dette gjøres ved hjelp av kommandoer som:
sudo metricbeat test config
sudo metricbeat test output
sudo metricbeat modules list

Hvis disse testene mislykkes, anbefales det å gjennomgå dokumentasjonen for Feilsøking av Metricbeatsiden feil vanligvis er relatert til feil påloggingsinformasjon, utilgjengelige endepunkter eller moduler som ikke er riktig aktivert. Når alt er bekreftet, kan du kjøre:
sudo metricbeat setup
for å laste inn standard dashbord og definere nødvendige indekstilordninger.

Til slutt startes Metricbeat i konsollutgangsmodus, eller som en tjeneste, med:
sudo metricbeat -e
Dette vil føre til at GPU-målingene som eksponeres av dcgm-exporter, begynner å bli kontinuerlig sendt til Elastic, hvor de lagres og er klare til å bli analysert.

Visualisering av minne- og GPU-målinger i Kibana

Når dataene flyter inn i Elastic Observability, begynner den interessante delen: å utforske, filtrere og kryssreferere GPU- og CPU-målinger for å virkelig forstå hva som skjer i infrastrukturen din. Dette gjøres primært ved hjelp av Kibana, Elastics nettbaserte analyse- og visualiseringsgrensesnitt.

Det første trinnet er å sørge for at indeksmønsteret metricbeat-* er riktig konfigurert i seksjonen Stakkhåndtering > Kibana > IndeksmønstreDerfra velger du mønsteret og klikker på «Oppdater feltlisten» slik at Kibana kan oppdage de nye feltene relatert til GPU-beregninger.

Målinger fra dcgm-exporter, samlet inn av Prometheus-modulen, vises vanligvis med et prefiks som prometheus.metrics.DCGM_ . Disse feltene inkluderer statistikk om minnebruk, ledig minne, GPU-bruksprosent, temperaturer, strømforbruk og andre relevante indikatorer.

Med disse feltene nå tilgjengelige, kan Kibanas Discover- visning brukes til å utføre ad hoc-søk , filtrere etter vert, GPU-navn eller tidsperiode. Det er også mulig å bygge visualiseringer i dashborddelen, som for eksempel viser utviklingen av GPU-minnebruk gjennom dagen eller sammenligner forskjellige forekomster i samme graf.

En av de mest praktiske visningene er Metrics Explorer, som lar deg sammenligne CPU- og GPU- ytelse på samme skjerm . Dette hjelper med å oppdage mønstre der for eksempel GPU-en er maksimalt utnyttet mens CPU-en er underutnyttet, eller omvendt, noe som indikerer potensielle problemer med arbeidsmengdebalansen.

Videre lar inventarvisningen deg finne kritiske GPU-brukspunkter i store distribusjoner , identifisere hvilke noder som er på grensen, hvilke som er inaktive og hvor flaskehalser er konsentrert. Derfra kan du definere varsler som utløses når for eksempel GPU-minne overstiger en viss terskel i en bestemt tidsperiode.

Viktige overvåkingsparametere i henhold til NVIDIA

Ikke alle målinger er like relevante når man optimaliserer et NVIDIA GPU-miljø på Linux. I følge produsentens anbefalinger er det noen viktige parametere som bør overvåkes kontinuerlig for å forhindre feil, oppdage ytelsesforringelse og finjustere strømforbruket.

GPU-temperatur er en av de mest åpenbare indikatorene. En vedvarende økning over trygge områder kan indikere kjøleproblemer, skitne vifter, dårlig luftstrøm i kabinettet eller til og med et termisk design som er utilstrekkelig for belastningen systemet er under.

En annen viktig målestokk er GPU-strømforbruket . Hvis et kort begynner å bruke mer strøm enn normalt for samme arbeidsmengde, kan det tyde på nye maskinvareproblemer eller en altfor aggressiv strøminnstilling. I store miljøer er disse dataene også avgjørende for å kontrollere strømkostnader og planlegge infrastrukturkapasitet.

Nåværende GPU-klokkehastigheter avslører også mye om systemets helse. Hvis disse klokkene holder seg under forventede verdier under tung belastning, kan det skyldes strømbegrensninger, termisk struping eller konservative strøminnstillinger som hindrer den faktisk tilgjengelige ytelsen.

For stresstesting eller validering tilbyr NVIDIA verktøy som dcgmproftester10Disse kommandoene lar deg simulere intensive GPU-belastninger og verifisere hvordan målingene reagerer. En typisk kommando ville være:
dcgmproftester10 --no-dcgm-validation -t 1004 -d 30
som kjører en spesifikk ytelsestest i 30 sekunder uten visse DCGM-valideringer, ideelt for å sjekke om systemet forblir stabilt under trykk.

Ved å kombinere disse målingene med Elastics varslingsfunksjoner er det mulig å automatisere anbefalinger foreslått av NVIDIA , utløse varsler når temperaturgrenser overskrides, når minnebruken nærmer seg 100 % farlig, eller når strømforbruket kommer betydelig ut av kontroll sammenlignet med normale referanseverdier.

Optimalisering av NVIDIA GPU-innstillinger på Linux

Utover passiv overvåking finnes det flere justeringer som kan brukes i Linux for å oppnå mer stabil og i mange tilfeller overlegen ytelse med NVIDIA GPU-er. Et av de mest relevante aspektene er å administrere funksjonene for automatisk boost og dynamisk klokkeskalering som er inkludert i selve driveren.

I noen GPU-tilfeller bruker NVIDIA-driveren en automatisk boost-funksjon som justerer GPU-frekvenser basert på belastning og termiske forhold. Selv om dette er nyttig for generelle miljøer, kan det i scenarier som krever maksimal ytelse og repeterbare resultater være å foretrekke å deaktivere disse funksjonene og manuelt stille inn klokkehastighetene til deres sikre maksimumsverdier.

Ved å deaktivere automatisk boost og angi maksimale frekvenser blir ytelsen mye mer konsistent og forutsigbar mellom kjøringer . Dette er spesielt viktig innen benchmarking, maskinvarevalidering, datasentre og AI-plattformer der minimal variasjon mellom kjøringer er avgjørende.

Et annet punkt å overvåke er GPU-ens strømmodus. På Linux lar NVIDIA-verktøy deg justere strømprofiler som spenner fra mer energieffektive moduser til moduser som gir vedvarende maksimal ytelse. Å velge en profil som er for konservativ kan begrense FPS i spill eller ytelsen i intensive databehandlingsoppgaver betydelig , selv om det reduserer strømforbruket.

På forbruker-PC-er, spesielt de som er designet for Linux-spilling med moderne grafikkort, er det lurt å sjekke at driverne er oppdaterte og at innstillingene for persistensmodus, strømgrense og klokkeprofil er justert med de ønskede ytelsesmålene. Dette er et område der mange negative referanseresultater rett og slett skyldes en dårlig optimalisert fabrikkkonfigurasjon.

Linux og spill med NVIDIA GPU-er: nåværende situasjon

Selv om Linux fortsatt lider av ryktet om å ikke være «den rette plattformen» for spilling, er realiteten at med et godt NVIDIA GPU og Steam-økosystemet er det fullt mulig å nyte mange titler med en opplevelse ganske lik Windows, spesielt hvis du benytter deg av moderne grafikk-API-er.

Steam Play, som bruker Proton og DXVK (en spesifikk forgrening av Wine) , oversetter DirectX-kall til Vulkan, slik at et stort antall spill som opprinnelig ble utviklet for Windows kan kjøre. Selv om nøyaktig native ytelse ikke alltid oppnås, er FPS-tapet vanligvis minimalt og i mange tilfeller akseptabelt for de fleste brukere.

I sammenligninger med tidligere generasjons kort, fra NVIDIA GeForce GTX 980 Ti til TITAN RTX , og AMD-modeller som Radeon RX Vega 56 eller Radeon VII, har man sett at NVIDIAs avanserte GPU-er med Turing-kjerner skiller seg ut spesielt ved 4K-oppløsning på Linux når det gjelder krevende spill.

Et illustrerende eksempel finnes i spill som Total War: Three Kingdoms , hvor mange av de 18 testede grafikkortene kan oppnå de ønskede 60 FPS ved 4K-oppløsning hvis et lavt detaljnivå opprettholdes. Når detaljnivået økes til middels, er det bare svært kraftige modeller som RTX 2080 Ti eller TITAN RTX som klarer å overgå denne terskelen konsekvent på Linux.

Andre titler som Counter-Strike: Global Offensive eller DOTA 2 viser mye mer tilgivende oppførsel: Ved å dra nytte av Vulkan API når det er tilgjengelig, kan så godt som alle testede kort kjøre dem jevnt i 4K, med høye FPS-rater selv på mindre avansert maskinvare innenfor det analyserte området.

I grafisk krevende spill som Deus Ex: Mankind Divided eller Dawn of War III blir behovet for avanserte grafikkort for å kunne spille i 4K med høye innstillinger nok en gang tydelig. I titler som Rise of the Tomb Raider eller A Total War Saga: Thrones of Britannia kan de fleste GPU-er håndtere 4K-oppløsning hvis detaljnivået er satt til lavt eller middels, noe som forsterker ideen om at NVIDIA har en fordel over AMD når det gjelder drivere og optimalisering for Linux i disse scenariene.

Et tilbakevendende tema i disse testene er at AMD fortsatt har rom for forbedring i sine Linux-spilldrivere , mens NVIDIA tilbyr mer moden støtte og mer konsistente oppdateringer. For de som søker best mulig ytelse i høyoppløselige spill på Linux, er dette fortsatt en nøkkelfaktor når de velger et GPU.

Samlet sett gir det deg muligheten til å få mye mer ut av kortet ved å forstå hvordan Linux-minnestatistikk og NVIDIA GPU-målinger oppfører seg, kombinert med god driverkonfigurasjon og overvåkingsverktøy, enten det er i en spill-PC, en AI-server eller et datasenter med dusinvis av noder som jobber med full kapasitet.

Det er tydelig at detaljert kontroll over minne, ytelse og statusen til NVIDIA GPU-er i Linux ikke lenger er valgfritt, men en nøkkelkomponent for både produksjonsmiljøer og krevende brukere: en god driverstabel og DCGM, et eksportlag for metrikker med dcgm-exporter, innsamling med Metricbeat og visualisering i Kibana, kombinert med finjustering av GPU-kraft og klokkehastighet, er det som virkelig utgjør forskjellen mellom et system som bare yter og et som klemmer hver watt og hver gigabyte med tilgjengelig minne til det fulle.