Minnefeilsøking i Linux: viktige verktøy og teknikker

Informatec Digital » Ressurser » Minnefeilsøking i Linux: Viktige verktøy og teknikker

Når noe går galt på en Linux-server, ligger årsaken ofte i hvordan minnet brukes og feilsøkingsverktøyene , men inntil du vet hva du skal se etter, virker alt som et kaotisk virvar av tall og prosesser. Å forstå hva som skjer i RAM, hvordan programmene dine oppfører seg og hvordan du fanger opp minnedumper er nøkkelen til å unngå blind feilsøking hver gang en merkelig feil eller segmenteringsfeil dukker opp.

I denne artikkelen skal vi ta en detaljert og enkel titt på hvordan man inspiserer minne, feilsøker programmer og analyserer dumps i Linux ved hjelp av systemkommandoer (free, vmstat, /proc/meminfo), feilsøkingsprogrammer som GDB, minneanalysatorer som Valgrind og verktøy spesifikke for .NET og andre miljøer. Målet er at du skal ha et praktisk arsenal for å diagnostisere minne- og CPU-problemer i servere og profesjonelle utviklingsmiljøer.

Oversikt: Minne i Linux og hvorfor du ikke bør overdrive det 100 %

På en Linux-server fungerer RAM som en rask lagringsplass for data og kode som systemet trenger å gjenbruke snart. Tilgang til RAM er mye raskere enn tilgang til disken, så kjernen utnytter dette til å bruke det som en hurtigbuffer for filer, buffere og minnesider som kan være nødvendige igjen snart.

I sammenheng med en webserver som kjører Apache eller Nginx , eller en databaseserver som MySQL eller MariaDB, er det viktig å vite hvor mye minne som er i bruk, hvor mye som er ledig og hvor mye som er mellomlagret for å kunne dimensjonere tjenester riktig og forstå navnerom og cgroups . Faktisk bruker optimaliseringsverktøy som MySQLTuner disse dataene (og annen informasjon) til å foreslå justeringer av buffer, mellomlag og tilkobling.

Det er viktig å forstå et konsept som ofte overrasker folk i starten: RAM er designet for å være i bruk . Å se 90 % eller til og med 100 % bruk er ikke nødvendigvis et problem; Linux fyller RAM med diskbuffer for å øke hastigheten på systemet. Det som virkelig er bekymringsfullt er når du begynner å få feilmeldinger om at minnet er tomt , prosesser krasjer med en OOM-melding (Out Of Memory), eller tjenester som fryser, ikke bare når grafen viser "høy bruk".

Det er bare fornuftig å gå over til aggressiv optimalisering hvis du merker at serveren blir ustabil, treg eller stopper tjenester på grunn av overdreven minnebruk, eller hvis du vet at trafikktopper kommer som kan overbelaste nåværende ressurser.

Grunnleggende kommandoer for å inspisere minne i Linux

Det første trinnet i feilsøking av minneproblemer er å forstå den totale RAM-mengden din og hvordan den er fordelt mellom brukt minne, ledig minne, hurtigbuffer og swap. Linux tilbyr flere verktøy for dette, hvert med et ulikt detaljnivå.

free-kommando: rask oversikt over RAM og swap

Den mest brukte kommandoen for en rask titt er gratis, spesielt med parameteren -h Slik viser du størrelser i et lesbart format: Hvis du vil ha mer informasjon om tolkning og optimalisering av disse målingene, kan du se optimalisere minnestatistikk.

free -h

Den typiske utdataen viser deg, på noen få linjer, totalt, brukt, ledig, delt, buffer- og hurtigminne , for både RAM og swap-plass. Du vil se noe slikt:

Totalt antall ledige delte buffere i mellomlagring Minne: 2.0 G 1.5 G 470 MB 300 MB 0 B 414 MB -/+ buffere/hurtigbuffer: 1.1 G 885 MB Bytte: 0 B 0 B 0 B

linje -/+ buffers/cache Det er spesielt nyttig fordi det viser deg minnet som faktisk brukes av prosesser (unntatt buffere/hurtigbuffer) og minnet som potensielt er tilgjengelig for nye applikasjoner. Mange ser lite "ledig minne" på den første linjen og blir urolige, når mye av det i virkeligheten bare er mellomlagret og kan gjenbrukt uten drama.

vmstat: aktivt, inaktivt minne og systemmålinger

Når du trenger noe mer detaljert, gir vmstat et mer teknisk bilde av systemet. Med:

vmstat -s -S M

Du vil få en liste med totalt minne, brukt minne, ledig minne, aktivt minne, inaktivt minne, buffere, swap-minne osv. For eksempel:

2048 M totalt minne 1582 M brukt minne 1124 M aktivt minne 406 M inaktivt minne 465 M ledig minne 0 M bufferminne 407 M swap-hurtigbuffer 0 M totalt swap 0 M brukt swap 0 M ledig swap

Konseptet med inaktivt minne er interessant: det er minne som anses å være i bruk, men som ikke er knyttet til aktive prosesser, så i praksis oppfører det seg som minne som systemet kan gjenopprette . Dette bidrar til å forklare hvorfor Linux kan virke som om det "bruker opp all plassen", men i virkeligheten har plass til å frigjøre når det er nødvendig.

/proc/meminfo: de rå kjernedetaljene

Hvis du vil ha alle detaljene som kjernen håndterer, kan du alltids ta en titt på /proc/meminfo -filen :

cat /proc/meminfo

Denne filen inneholder dusinvis av felt relatert til intern minnehåndtering : totalt minne, ledig minne, buffere, hurtigbuffer, slab, hugepages, tilgjengelig minne osv. Den er veldig nyttig for automatiserte verktøy og overvåkingsskript, selv om det å lese den direkte er noe mindre brukervennlig enn `free` eller `vmstat` og krever en grundig forståelse av hva hvert felt betyr.

Kontrollpaneler og deres «parallelle virkelighet»

Hvis du administrerer en server med kontrollpaneler som cPanel, Plesk, VestaCP eller Webmin , vil du se at de vanligvis viser grafer over brukt, ledig og hurtigbufret minne via et webgrensesnitt. Disse dataene er praktiske, men husk at de oppdateres med jevne mellomrom og noen ganger ikke gjenspeiler den nøyaktige sanntidsstatusen. For grundig diagnostikk og finjustering er det alltid best å bruke terminalen og dens innebygde kommandoer.

Feilsøking av prosesser og minne med systemverktøy

Når du vet hvor mye minne som er tilgjengelig og hvordan det brukes generelt, er neste trinn å finne hvilke prosesser som bruker ressurser unormalt og analysere oppførselen deres. Det er her klassiske verktøy som ps, top, htop, strace og ltrace kommer inn i bildet, i tillegg til nettverks- og diskkommandoer som bidrar til å eliminere flaskehalser.

ps, top og htop: et røntgenbilde av prosesser og CPU

`ps`- kommandoen viser aktive prosesser. Kombinert med filtre og sortering lar den deg raskt finne hva som bruker CPU-en.

ps aux --sort=-%cpu | head

Dette viser deg prosesser sortert etter CPU-bruksprosent , sammen med minnebruk, bruker og kommando. Det er ideelt som et øyeblikksbilde for å identifisere den hovedmistenkte når serveren har lite ressurser. Å mestre terminalen hjelper deg med å handle raskt.

På den annen side tilbyr `top` og den mer visuelle varianten `htop` en sanntidsvisning av prosesser, CPU-bruk, minnebruk, tilstand (R, S, D, osv.) og gjennomsnittlig belastning . Starter `top` med:

top -o %CPU

Du kan fokusere på hvilke prosesser som bruker mest CPU. Utover tallene er det viktig å se etter mønstre :

• Prosesser i R-tilstand (kjører) som blir liggende fast på toppen lenge.
• Plutselige endringer i gjennomsnittlig belastning som indikerer nylige belastningstopper.
• CPU-allokering i %us, %sy og %wa (brukertid, systemtid og I/O-ventetid).
• Hvis den problematiske prosessen er en systemtjeneste, en bestemt bruker eller en daemon.
• Hvis forbruket er stabilt eller Det går opp og ned i rykk og napp., som kan tyde på batchoppgaver eller uregelmessig trafikk.

En veldig høy %wa- verdi (I/O-ventetid) er et tegn på at flaskehalsen kanskje ikke ligger i CPU-en, men i disken eller lagringsundersystemet.

Gjennomgang av tråder i en prosess: topp -H

For flertrådete applikasjoner (Java, Python, Node, osv.) er det ikke nok å vite hvilken prosess som bruker CPU; du må se hvilken spesifikk tråd som går ut av kontroll . Med:

top -H -p PID

Du får detaljene for hver tråd i prosessen. Hvis én av dem vises på 100 % og resten er inaktive, er det sannsynligvis en uendelig løkke, et merkelig blokkeringsproblem eller en dårlig utformet kritisk seksjon i den delen av koden.

Prosessprioritet: fin og ren fin

Hvis en ressurskrevende prosess er legitim, men du vil forhindre at den overbelaster resten av systemet, kan du justere prioriteten (niceness) . Kommandoene `nice` og `renice` lar deg starte prosesser med lavere prioritet eller justere prioriteten til en eksisterende prosess, slik at kjernen tildeler mindre CPU-tid til dem sammenlignet med andre kritiske oppgaver.

Andre viktige kommandoer: pidof, kill, strace og ltrace

Når systemet er under press, er det nyttig å raskt kunne finne og kontrollere prosesser:

• pidof: henter PID-en til en prosess fra navnet, perfekt for skript eller raske inngrep.
• drepesender signaler til prosesser (TERM, KILL, osv.), enten om å stenge ned på en ordnet måte eller forkorte jobben hvis de har kjørt seg fast.
• strace: viser systemanrop som utfører en prosess; ideell for å se hva den sitter fast på (disklesninger, sokkeler osv.).
• sporeLigner på strace, men fokusert på samtaler til bokhandlere, nyttig for feilsøking av problemer med bruk av delte API-er.

Disse verktøyene er ikke bare nyttige for å jakte på minnelekkasjer eller krasj, de er også mye brukt i cybersikkerhet, rettsmedisinsk analyse og feilsøking av merkelig binær oppførsel .

Kommandoer for filer og disk: lsof, df, du, locate

Når du mistenker at noe er galt med lagringen (for eksempel mange åpne filer eller fulle disker), kommer andre kommandoer i spill:

• lsof: liste opp filer åpnet av en prosess, nyttig for å finne lekkasjer av beskrivelser eller filer som hindrer at et filsystem avmonteres.
• df: viser ledig diskplass etter filsystem, viktig for å utelukke 100 % av disker som forårsaker kaskadefeil.
• du: beregner plass brukt av kataloger, veldig nyttig for å finne mapper som vokser ukontrollert (logger, sikkerhetskopier osv.).
• finne: lar deg søke etter en fil etter navn ved hjelp av en indeksert database, raskere enn finn i mange situasjoner.

Nettverkskommandoer for diagnostikk: nc, netstat, ab, tcpdump, wireshark, nmap

Ofte er ytelses- og minneproblemer ledsaget av nettverksflaskehalser eller angrep , så det er lurt å ha noen grunnleggende verktøy for hånden:

• nc (nettkatt)en ekte sveitsisk lommekniv innen nettverk; åpner stikkontakter, sender og mottar data, muliggjør tjenestetesting, til og med improviserte tunneler.
• netstatviser aktive tilkoblinger, lyttesokler og nettverksstatistikk, nyttig for å se om det er mange tilkoblinger til en bestemt port.
• ab (Apache Benchmark)genererer en belastning mot en webserver for å måle responstider og oppførsel under stress.
• tcpdump og WiresharkDe fanger opp nettverkspakker for å analyser trafikken i dybden; tcpdump i konsollen, Wireshark med grafisk grensesnitt.
• nmapPort- og tjenesteskanner, mye brukt til både sikkerhetsrevisjoner og kontroll av servereksponeringsoverflate.

GDB: den klassiske feilsøkingsprogrammet for minnefeil og krasj under kjøring

Når et Linux-program krasjer med en segmenteringsfeil eller en annen større feil, er det neste logiske steget å bruke en god feilsøkingsfunksjon. Stjerneverktøyet i GNU-verdenen er GDB (GNU Debugger) , som lar deg inspisere et programs interne tilstand, stoppe det hvor du vil, se variabler og minnebruk, og følge utførelsen trinn for trinn.

GDB ble opprinnelig designet for C- og C++-programmer, men det har blitt utvidet til andre språk som Rust og til og med Assembly , og til håndtering av bibliotekstier som LD_LIBRARY_PATH . Det er grunnleggende i utvikling, men også i cybersikkerhet, hvor det brukes til reverse engineering, å finne sårbarheter og utvikle eller feilsøke utnyttelser.

Start GDB og kjør et program

For å bruke GDB med en kjørbar fil, anbefales det å kompilere programmet med feilsøkingsinformasjon ved å bruke alternativet -g fra GCC:

gcc -g -Wall programa.c -o programa

Så starter du den med:

gdb programa

I GDB kjører ikke programmet ennå. Du kan starte det med:

• løpeStart programmet med hvilke som helst argumenter du ønsker.
• Begynnsamme som run, men stopper i begynnelsen av funksjonen main.

Hvis du har en kjørbar fil som heter for eksempel Suma Og hvis du vil se hvordan den behandler argumentene sine, går du inn i GDB og bruker deretter run 3 5 for å starte den med disse parameterne fra feilsøkingsprogrammet.

Brytningspunkter og overvåkningspunkter: sette programmet på pause der det er nødvendig

Brytpunkter er stopppunkter i kildekoden: når kjøringen når dem, stopper programmet midlertidig, og du kan inspisere dets interne tilstand. I GDB defineres de med kommandoen :

break lugar

hvor «plassering» kan være et funksjonsnavn, linjenummer eller fil:linje . Et typisk eksempel ville være:

break main

slik at GDB stopper akkurat idet den går inn i hovedfunksjonen. Når programmet stopper ved et stoppunkt, kan du se kode med l (liste), sjekke variabler og navigere i kallstakken.

Overvåkningspunkter fungerer annerledes: i stedet for å stoppe på et bestemt punkt i koden, stopper de når verdien av en variabel endres . De er svært nyttige for å oppdage minnekorrupsjon eller uventede endringer i kritiske strukturer uten å måtte oversvømme koden med print-setninger.

Fin flytkontroll: trinn, neste, fortsett, fullfør

Når programmet har stoppet ved et avbruddspunkt, har du flere måter å fortsette på:

• trinn: utfører følgende linje og skriver inn de kalte funksjonene.
• nestekjører følgende linje uten å legge inn funksjonene (kjører dem "alle samtidig").
• fortsettegjenopptar kjøringen til neste avbruddspunkt eller til programmet avsluttes.
• ferdigfortsetter til den gjeldende funksjonen returnerer og går tilbake til punktet der den ble kalt fra.

Dette lar deg inspisere mistenkelig kode trinn for trinn, uten å måtte "svelge" hele programmet. Et hendig triks: i GDB, Å trykke Enter gjentar den siste kommandoenideell for å lage mange next o step etterfulgt av mindre skriving.

Anropsstabel og rammer: se hvordan vi kom hit

For å forstå hvorfor en feil oppsto på et bestemt tidspunkt, er det viktig å se hvilke funksjoner som ble kalt frem til det tidspunktet. Strukturen som lagrer denne informasjonen er kallstakken . GDB tilbyr flere kommandoer for å administrere den:

• bt (backtrace): viser hele stakken, med listen over nestede funksjoner og rammenumre.
• up: flytter seg opp ett nivå i stakken, til punktet som kalte den gjeldende funksjonen.
• ned: går ned ett nivå, til funksjonen som kjørte.
• fr (ramme): viser gjeldende ramme eller lar deg bytte til en annen ved å angi nummeret.

Dette lar deg posisjonere deg selv på forskjellige nivåer av kallet (for eksempel hoppe fra en intern funksjon til main ) og se hvordan variablene var på hvert sted.

Interaksjon med minne: sett, retur, tilbakesporing yx

En av de store fordelene med GDB er at den lar deg lese og endre minne mens programmet er stoppet. Noen nyttige operasjoner inkluderer:

• sett: endrer verdien til en variabel under utførelse, ideelt for testing av scenarier uten rekompilering.
• returverditvinger den gjeldende funksjonen til å returnere den angitte verdien, uten å fortsette å kjøre koden.
• tilbakesporingallerede sett, for å vise gjeldende kallstakk.
• x: undersøker minneinnhold fra en adresse, med forskjellige formater og størrelser (for eksempel, x/4xw 0x7fffffffe000 for å se fire ord i heksadesimal).

Med disse alternativene kan du gjenskape feil, sjekke om farlig inndata forårsaker overløp, eller inspisere komplekse datastrukturer på stakken eller heapen.

Feilsøking etter død med kjernedumper

Linux kan generere en kjernefil når en prosess krasjer på grunn av et signal som SIGSEGV. Denne filen inneholder prosessens fullstendige tilstand på krasjetidspunktet: minne, registre, stakk osv. For å aktivere den i en økt, gjør du ganske enkelt følgende:

ulimit -c unlimited

For å aktivere dem mer permanent for brukere, kan du redigere /etc/security/limits.conf og legge til en linje som denne:

* soft core unlimited

Når et program krasjer, genererer det en fil som vanligvis kalles «core» i arbeidskatalogen. Du kan deretter analysere den med GDB slik:

gdb ejecutable core

Dette lar deg utføre en post mortem-analyse nesten som om programmet fortsatt var i live, ideelt når feilen ikke er lett å reprodusere på forespørsel.

Valgrind: jakter på minnelekkasjer og feil

For mange minneproblemer i C/C++ (og lignende språk) er GDB utilstrekkelig fordi den ikke er designet for å automatisk oppdage ulovlige lesninger, lekkasjer eller uinitialisert minnebruk . Det er her Valgrind kommer inn i bildet – et feilsøkings- og profileringssystem som emulerer prosessoren og overvåker all minnetilgang.

Valgrind inkluderer flere verktøy, men det mest brukte er Memcheck , som erstatter Cs standard minnebehandler med sin egen, med beskyttelsessoner rundt tildelte blokker . Dette lar den oppdage:

• Uinitialisert minnebruk (variabler som brukes før de tildeles en verdi).
• Lesing/skriving etter å ha gjort fri (bruk-etter-fri).
• Tilgang utenfor grensene av en minneblokk.
• Minnelekkasjer (malloc uten gratis, tapte pekere osv.).

Feilfritt eksempel: «rent» program under Memcheck

Anta at du kompilerer et lite "hallo verden"-program med feilsøkingsinformasjon:

gcc -Wall -gstabs valgrind_hello_good.c -o valgrind_hello_good

Hvis du kjører det under Valgrind med:

valgrind --tool=memcheck --leak-check=full -v ./valgrind_hello_good

Du vil få et spor der FEILSUMMARIFFET til slutt indikerer 0 feil og ingen lekkasjer er rapportert. Dette bekrefter at programmet, i hvert fall fra Memchecks synspunkt, ikke viser minneavvik.

Oppdag minnelekkasjer

Hvis du endrer koden til å gjøre en malloc uten å frigjøre (for eksempel ved å reservere en byte og aldri frigjøre den) og kompilerer på nytt:

gcc -Wall -gstabs valgrind_hello_bad.c -o valgrind_hello_bad

når du kjører:

valgrind --tool=memcheck --leak-check=full -v ./valgrind_hello_bad

Valgrind vil vise et HEAP SUMMARY med en verdi som ikke er null for «in use at exit», som indikerer mengden uutgitt minne. I tillegg vil delen «definitivt tapt» vise antall lekkede byte og blokker, sammen med kallsporet som forårsaket lekkasjen (funksjon, fil og kodelinje).

For mer komplekse tilfeller, der filtre brukes, for eksempel, 100 byte i en leak()-funksjonUtgangen fra Valgrind vil tydelig peke deg mot malloc problematisk, noe som tillater tillegg av free tilsvarende og verifiser etterpå at oppsummeringen går tilbake til null lekkasjer.

Ulovlige handlinger og tilgang utenfor rekkevidde

En annen typisk feil som Memcheck oppdager er skriving til ugyldige adresser , for eksempel skriving til minneplassering 0 (NULL) eller utover slutten av en array. Hvis du kompilerer et program som utfører en ulovlig skriving:

gcc -gstabs -Wall valgrind_illegal_read_write.c -o valgrind_illegal_read_write

og du kjører den med:

valgrind -v ./valgrind_illegal_read_write

Du vil se meldinger som:

Ugyldig skriving av størrelse 4 ved 0x80483C4: main (valgrind_illegal_read_write.c:8) Adresse 0x0 er ikke stablet, mallocert eller (nylig) frigjort.

Dette forteller deg nøyaktig hvor den ulovlige skrivingen skjedde og hvor stor den var, noe som i normale utførelser vanligvis manifesterer seg som en enkel "segmenteringsfeil" uten ytterligere ledetråder.

Uinitialiserte variabler og deres verdiavhengigheter

Memcheck varsler deg også når en Kontrollbeslutningen avhenger av en uinitialisert variabelHvis du kompilerer et program med en lokal variabel som aldri initialiseres og brukes i en if:

gcc -gstabs -Wall valgrind_unitialized.c -o valgrind_unitialized

og du kjører den med:

valgrind -v --track-origins=yes ./valgrind_unitialized

Utdataene vil inneholde noe slikt som:

Betinget hopp eller bevegelse avhenger av uinitialiserte verdier ved 0x80483F2: main (valgrind_unitialized.c:9) Uinitialisert verdi ble opprettet av en stakkallokering ved 0x80483EA: main (valgrind_unitialized.c:7)

Parameteren –track-origins=yes hjelper med å finne hvor den uinitialiserte variabelen først ble opprettet, noe som øker hastigheten på kodekorrigeringen betraktelig.

Misbruk av fri- og feildeteksjon i heapen

Valgrind bekrefter også at free kalles bare på gyldige pekereHvis du prøver å frigjøre minne som ikke kommer fra mallocEller hvis du dobbeltklikker på den samme blokken, får du meldinger som denne:

Ugyldig free() / delete / delete[] / realloc() ved 0x402B06C: free (...) av 0x8048449: main (valgrind_illegal_free.c:11)

I mange tilfeller forteller den deg til og med at adressen du ringer fra free Den er plassert rett etter en blokk som allerede er frigjort, noe som tillater identifisering pekerberegningsfeil eller dobbeltutgivelser.

Oppsummert er Valgrind et viktig verktøy når du mistenker minnelekkasjer, use-after-free eller minnekorrupsjon i native programmer, og kombinert bruk med GDB gir et svært kraftig bilde av applikasjoners interne tilstand.

Kjernedumper og -analyse i Linux og Windows

I moderne applikasjoner, spesielt i .NET Core , innebærer analyse av komplekse minne- eller ytelsesproblemer ofte å hente minnedumper for nøye analyse på en annen maskin. Disse dumpene fryser prosesstilstanden på et bestemt tidspunkt, akkurat som en tradisjonell kjernedump.

Analysere .NET-dumper på Linux med dotnet-dump og LLDB

I .NET Core-miljøer på Linux er et av de anbefalte verktøyene dotnet-dump . Etter at du har fanget en dump, kan du starte analysen med:

dotnet-dump analyze <dump-file>

Det er viktig at analysen utføres på en maskin med samme arkitektur og Linux-distribusjon som miljøet der dumpen ble generert. dotnet-dump er rettet mot administrert .NET-kode; for å også analysere native kode (C/C++) er det mer passende å bruke LLDB sammen med SOS- utvidelsen.

LLDB lar deg feilsøke både administrert og native kode, og med hjelp av dotnet-sos kan du installere SOS-utvidelsen, som gir spesifikke kommandoer for .NET. For å laste inn en .NET Core-dump riktig, krever LLDB og SOS visse binærfiler fra miljøet der dumpen ble opprettet:

1. libmscordaccore.so
2. libcoreclr.so
3. dotnet (verten som ble brukt til å starte applikasjonen)

Disse binærfilene kan vanligvis lastes ned ved hjelp av dotnet-symbol- verktøyet . Hvis det er en privat versjon , eller de ikke er på symbolserveren, kan du alltid kopiere dem fra den opprinnelige maskinen. Hvis binærfilene ikke er inkludert i dumpfilen, kan du bruke følgende i LLDB/SOS:

• setclrpath <ruta> for å indikere hvor .NET Core-binærfilene er plassert.
• setsymbolserver -directory <ruta> for å angi plasseringen av symbolene.

Når du har alt du trenger, laster du dumpen inn i LLDB, og spesifiserer dotnet-verten som den kjørbare filen for feilsøking:

lldb --core <dump-file> <host-program>

Her Det er veien til dumpingen og Det er vanligvis binært. dotnet, med mindre det er et selvstendig program, i så fall ville det være appens egen kjørbare fil (uten .dll-utvidelsen).

Innenfor LLDB er det ofte nødvendig å konfigurere riktig symbolserver med setsymbolserver -ms å bruke Microsoft-serveren, eller setsymbolserver -directory <ruta> for en lokal katalog, og kjør loadsymbols for å laste inn de opprinnelige symbolene. Derfra kan du bruke de vanlige SOS-kommandoene til å analysere den administrerte heapen, tråder, unntak osv.

Linux-dumpanalyse fra Windows

Dumpene som genereres i Linux er ikke begrenset til å bli analysert på det samme systemet; de kan også åpnes fra Windows med verktøy som Visual Studio, WinDbg eller dotnet-dump. Funksjonene varierer:

• Visual Studio: tillater rengjøring av søppelfyllinger med en blanding av innebygd og administrert kodemed et svært brukervennlig grafisk grensesnitt. Det anbefales å se gjennom den spesifikke veiledningen for Feilsøking av minnedumper i Visual Studio.
• WinDbgAvansert støtte for brukerdumper, inkludert Linux-dumper med en arbeidsflyt som ligner på Windows. Du må bruke x64-versjonen av WinDbg for dumps fra Linux x64- eller Arm64-miljøer, og x86-versjonen for x86-dumps.
• dotnet-dump På Windows: den brukes på samme måte som på Linux, med dotnet-dump analyzeHusk å velge x64- eller x86-versjonen av verktøyet i henhold til arkitekturen til dumpen.

Profesjonell diagnose av høy CPU- og minnebruk

Utover spesifikke verktøy innebærer minnerydding i Linux vanligvis en strukturert arbeidsflyt for å unngå tilfeldige handlinger. En praktisk ordning for servere er som følger:

• se topp for å oppdage mistenkelige lastemønstre og -prosesser.
• Bekreft med ps prosessene som bruker mest CPU og minne.
• Sjekk om forbruket er logisk (kompileringer, batch, indeksert) eller lukter av unormal oppførsel.
• Analyser tråder med topp -H -p PID når det gjelder flertrådede prosesser.
• For å se gjennom tjenestelogger med journalctl eller tail.
• Sjekk om problemet virkelig er CPU-relatert eller skjult i... disk I/O ved hjelp av iostat.

For å avgjøre om flaskehalsen ligger i CPU-en eller disken, er iostat -xz 1 3 veldig nyttig: hvis du ser disker med høy utnyttelse og lange ventetider, sammen med en høy %wa i top , er problemet sannsynligvis ikke CPU-en, men lagringen.

Ved å bruke denne arbeidsflyten er det enklere å diagnostisere tilfeller som:

• Bots eller ondsinnet trafikk utløser php-fpm-prosesser og overbelaster webserveren.
• Un Java-mikrotjeneste med en tråd i en uendelig løkke forbruker en hel kjerne.
• En Python-prosess som ser ut til å være CPU-bundet, men som egentlig er det låst venter på disk i hver iterasjon av en løkke.

Ved å kombinere systemverktøy (ps, top, vmstat, free), feilsøkingsprogrammer (GDB, LLDB, dotnet-dump), minneanalysatorer (Valgrind) og nettverks- og diskkommandoer, kan du lage en arbeidsmåte der minne- og ytelsesproblemer i Linux slutter å være en svart boks og blir noe som med metode og tålmodighet kan identifiseres og korrigeres med betydelig nøyaktighet.