Nøkkelfaktorer for å finne en ressursflaskehals i Linux-serveroverbelastning

Av | november 10, 2021

Det er svært vanlig, til tross for rimelig maskinvare, å ha lastproblemer på serveren. Det kan være flere årsaker til høy belastning på serveren, for eksempel utilstrekkelig RAM/CPU, tregere harddisker eller rett og slett ikke-optimalisert programvare. Denne artikkelen vil hjelpe deg med å identifisere hva en flaskehals er og hvor du skal investere. Vennligst ikke ta det som en erstatning for profesjonell rådgivning / service. Du bør alltid se etter en profesjonell tjeneste hvis du har råd til de tilhørende kostnadene.

I) Først av alt, har du virkelig problemer?

Vanligvis søker folk etter belastning på kontrollpanelene ved å bruke kommandoen «oppetid» eller «topp». Du kan sannsynligvis kjøre «oppetid»-kommandoen på rotskallet for å finne ut hva belastningen er, men jeg vil at du skal bruke «topp» for nå (vær så snill). Dette vil hjelpe deg med å identifisere hvor mange CPUer som blir rapportert *. Du bør kunne se noe som cpu00, cpu01, og så videre.

En belastning på ~ 1 for hver CPU er rimelig. For eksempel har du det bra hvis belastningen er 3,50 og du har 4 CPUer.

En annen ting å huske på når du ser på belastningen gjennom aktivitetstid eller høyere, er å forstå hva den viser. For eksempel: (på en 2HT CPU-server, angitt som 4)

18:30:55 til 17 dager, 5:17, 2 brukere, gjennomsnittlig opplasting: 4,76, 2,97, 2,62

Den første delen (3,76) viser gjennomsnittlig belastning de siste 5 minuttene, mens den andre (2,97) og den tredje (2,62) viser gjennomsnitt på henholdsvis 10 og 15 minutter. Det er sannsynligvis en topp her som jeg ikke ville bekymre meg for mye (litt bekymringsløs?), Men hvis du er det, fortsett å lese!

Er du veldig fornøyd med hvordan du klarte å identifisere at serveren din faktisk er overbelastet? Beklager, men du vet aldri fordi noen ganger kan servere håndtere mye mer belastning enn det som vises. Belastningsgjennomsnitt er ikke like nøyaktige og er kanskje ikke alltid den avgjørende faktoren. Forvirret? Det var bare teknisk informasjon som ikke trenger å plage deg så mye. Fortsett hvis lastene dine er til bekymring.

* merk bruken av begrepet «informert». Jeg brukte dette begrepet fordi en P4 CPU med HT-teknologi vil bli rapportert som 2, selv om du vet at serveren din har en CPU.

II) Hvor er problemet?

For å identifisere problemet må du kjøre en rekke logiske tester (ok, det er ikke så skummelt som det høres ut). Alt du trenger er litt fritid, sannsynligvis 30-45 minutter, og root-tilgang til serveren din (ikke forvent magi;)). Klar til å komme i gang? Her går vi!

Merk: Gjør kontrollene flere ganger for å komme til en god konklusjon.

1. Sjekk RAM (den vanligste flaskehalsen!).

# fri -m

Utgangen skal se slik ut:

# fri -m

totalt gratis delte buffere brukt i cachen

Mem: 1963 1912 50 0 28 906

– / + buffere / skjult: 978 985

Endringer: 1027 157 869

Enhver reaksjon som «Herregud, nesten all RAM har gått tom.»? Ikke vær redd. Ta en titt på bufferene / cachen som sier at «985» mb RAM fortsatt er ledig i bufferne. Så lenge du har nok minne i bufferne og serveren din ikke bruker mye swap, er du ganske god med RAM. Serveren din begynner å bruke SWAP (som Pagefile), som er en del av disken din som er allokert som minne, men den er relativt treg og kan bremse systemet enda mer hvis du har en travel harddisk (noe jeg tviler på at du vil). ville gjort hvis du bruker så mye RAM). Kort sagt, minst 175 MB tilgjengelig i buffere og ikke mer enn 200 MB utveksling.

Hvis RAM er problemet, bør du sannsynligvis se på optimaliseringer for PHP / Perl-skriptene, spørringene + MySQL-serveren og Apache.

2. Sjekk om I/O-bruken (input/output) er overdreven

Hvis det er for mange lese-/skriveforespørsler på en enkelt harddisk, vil den gå tregt og du må oppgradere den til en raskere stasjon (med flere RPM og cache). Alternativet til en enkelt raskere stasjon er å dele belastningen i flere stasjoner ved å spre det meste av innholdet i applikasjonen på flere stasjoner, noe som enkelt kan oppnås gjennom «symbolske lenker» (myke lenker til filer/mapper). For å identifisere, hvis I/O-problemet ditt forsinker serveren din:

# overlegen

Les utdataene i «iowait»-delen for hver CPU. I ideelle situasjoner bør den være nær 0 %. Men hvis du undersøker på tidspunktet for en belastningstopp, bør du vurdere å sjekke disse verdiene på nytt flere ganger for å komme til en god konklusjon. Alt over 15 % er bekymringsfullt. Du kan deretter sjekke hastigheten på harddisken for å se om den virkelig henger etter:

Hvis du vet at harddisken din finnes i / dev / sda eller / dev / hda, gjør du følgende. Eller kjør kommandoen «df -h» for å sjekke hvilken stasjon dataene dine ligger på.

# hdparm -Tt / dev / sda

Veien ut:

/ dev / sda:

Hurtigbuffertid: 1484 MB på 2,01 sekunder = 739,00 MB/s

Diskleser med buffer: 62 MB på 3,00 sekunder = 20,66 MB/s

Det var utrolig å lese cachebuffere, sannsynligvis på grunn av den innebygde diskcachen, men bufferdiskavlesningene er bare 20,66 MB/sek. Alt under 25 MB er noe du bør bekymre deg for.

3. Er all kraften til CPU-en forbrukt?

# overlegen

Sjekk topputgangen for å finne ut om du bruker for mye CPU-kraft. Du bør se etter tomgangsverdien i tillegg til hver CPU-inngang. Alt under 45 % er noe du bør være bekymret for.

III) Problem identifisert, hva er løsningen?

For å avslutte, la meg tilby noen løsninger for hvert problem:

En global løsning på alle problemer er å optimalisere MySQL og webserveren, inkludert PHP/Perl-skript og spørringer. Eller det minste du kan gjøre er å optimalisere Apache- og MySQL-serverinnstillingene for å fungere bedre.

1. For mye CPU-bruk

I «ps -auxf» eller «top» se etter prosesser som bruker for mye CPU. Hvis det er HTTP eller MySQL, bør du optimalisere skriptene og spørringene dine, hvis mulig. I de fleste tilfeller er det ekstremt vanskelig å optimalisere alle skript og spørringer, og et bedre alternativ er å bare gjøre en CPU endring/oppgradering. En dobbel CPU burde fungere bedre, men typen oppgradering du leter etter avhenger av din nåværende CPU.

2. RAM-minnet er oppbrukt

Det er som om du er i samme type situasjon som CPU. Optimaliser HTTP, MySQL, skript, etc. eller velg en RAM-oppgradering. Du kan installere Opcode cache-programvare som APC (fra Pear) for PHP for å få det til å fungere bedre samtidig som det reduserer belastningen.

3. Disken er alt brukt (eh, jeg mener ikke plass)

Her må du gå for en raskere stasjon som SATA over vanlig IDE eller SCSI over SATA. Vel, jeg snakket bare generelt. Du må vurdere faktorer som RPM og cache for å ende opp med å gjøre en verdig oppgradering. Det andre alternativet er å skaffe flere enheter av samme klasse og fordele belastningen mellom enhetene. En vanlig metode er å betjene MySQL fra en annen stasjon.

IV) Konklusjon

Var ikke det veldig nyttig? Artikkelen min kan være defekt, ahh, unnskyld meg. Det er min første artikkel, og denne tingen konsumerte virkelig mange av hjernecellene mine. Det er litt personlig, er det ikke? La oss komme tilbake til virksomheten.

For deg, i eksemplet, var problemet at bruken av I/O og at harddisken ble tregere.

En guide kan aldri være komplett alene eller tilby deg alt du trenger for å nå ekspertnivået (du må fortsette å lære for å nå det nivået). Hvis du er i tvil, ansett eksperter for å vurdere serveren din. På en eller annen måte, hvis du ikke har penger å bruke, er du fortsatt trygg! Du kan gå til hjelpeseksjonen vår for serveroptimalisering for å få hjelp med serveroptimaliseringen.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.