Naujausias pranešimas: Samba kritinis pažeidžiamumas
frame

Sveiki apsilankę!

Jei forume lankaisi pirmą kartą, kviečiame registruotis ir prisijungti prie diskusijų.

Prisijungti Registruotis

Dedikuoto serverio problemų diagnozė

IV_RomanLIV_RomanL Interneto vizija
edited 2019 rugsėjo 24 Į Tipinės problemos
Kokių konkrečių veiksmų reiktų imtis norint lokalizuoti galimas nepageidaujamas dedikuoto serverio apkrovas? Šiame informaciniame straipsnyje pateikiamos gairės kuriomis vadovaujantis galėsite nustatyti nemažą dalį problemas keliančių priežasčių ir jų galimus sprendimus. Bet kokiu atveju, problemas diagnozuoti ir jas šalinti turėtų jūsų dedikuoto serverio administratorius, tokiu būdu rizika suklysti bus minimali.

1. Padidėjęs serverio procesoriaus apkrovimas

Atsiradus dedikuoto serverio sutrikimui dėl aukšto procesoriaus panaudojimo, reiktų nustatyti kas išnaudoja šį resursą. Priežastys galinčios lemtį šį sutrikimą:

* Nepakankama esamo dedikuoto serverio procesoriaus galios serveryje vykdomoms programoms;
* Staiga padidėjus vykdomų programų skaičiui;
* Dėl nekorektiškai veikiančios (-ų) programos (-ų);

Prisijungiame prie serverio SSH konsolės ir vykdome komandą:
top
ir tuomet nuspauskite klavišus SHIFT + M

Prieš jūsų akis turėtų būti pateikta grafa, pavyzdys:
top - 14:08:25 up 38 days, 8:02, 1 user, load average: 1.70, 1.77, 1.68
Tasks: 107 total,   3 running, 104 sleeping,   0 stopped,   0 zombie
Cpu(s): 11.4%us, 29.6%sy, 0.0%ni, 58.3%id, .7%wa, 0.0%hi, 0.0%si, 0.0%st
Mem:   1024176k total,   997408k used,    26768k free,    85520k buffers
Swap:  1004052k total,     4360k used,   999692k free,   286040k cached

  PID USER    PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 9463 mysql   16   0  686m 111m 3328 S   53  5.5 569:17.64 mysqld
18749 apache  16   0  140m 134m 1868 S   12  6.6   1345:01 php_defunct
24636 apache  17   0 34660  10m  712 S    8  0.5   1195:15 php_defunct
22442 apache  24   0  6048 2024 1452 S    8  0.1   0:00.04 php_defunct
Pateikta lentelė su realiu laiku veikiančiomis aplikacijomis dedikuotame serveryje. Paanalizuokime pateiktus duomenis.

Eilutė:
Cpu(s): 11.4%us, 29.6%sy, 0.0%ni, 58.3%id, .7%wa, 0.0%hi, 0.0%si, 0.0%st
čia:

* us: vartotojo CPU laikas (user CPU time) - tai reikšmė parodanti kokios aplikacijos veikia varotojo vardu. Šiuo atveju pagal pavyzdį veikia "mysql" ir "apache" programos. Jei ši reikšmė yra didesnė už kitas, reiškia apkrova generuoja vartotojo vykdoma programa.
* sy: sistemos CPU laikas (system CPU time) - tai pačios operacinės sistemos branduolio apkrovos reikšmė.
* id: budinčio CPU procentas (idle CPU time) - ši reikšmė parodo kiek procentų CPU nėra panaudojamas. Kuo ši reikšmė didesnė tuo geriau. Jei ši reikšmė itin didelė (daugiau nei 80-85 procentai) tai indikuoja jog sistemos sulėtėjimą lemia ne CPU resurso perkrova.
* wa: nuskaitymo/įrašymo laukimas (I/O wait) - ši reikšmė parodo laiką kurį turi laukti CPU iki kol bus įrašyti/nuskaityti duomenys (dažniausiai kietojo disko). Jei ši reikšmė itin didelė ir jūsų dedikuoto serverio darbas sulėtėjęs, tai gali reikšti kietojo disko problemą arba RAM gedimą.

Eilutė:
   PID USER    PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
  9463 mysql   16   0  686m 111m 3328 S   53  5.5 569:17.64 mysqld
 18749 apache  16   0  140m 134m 1868 S   12  6.6   1345:01 php_defunct
24636 apache  17   0 34660  10m  712 S    8  0.5   1195:15 php_defunct
22442 apache  24   0  6048 2024 1452 S    8  0.1   0:00.04 php_defunct
Čia:

* CPU: indikuoja dedikuotame serveryje veikiančios aplikacijos CPU sunaudojimą. Kuo šis skaičius didesnis, tuo daugiau aplikacija reikalauja CPU galios. Jei matote jog šis skaičius itin didelis ties viena iš aplikacijų (pvz.: mysql), tuomet problema mySQL serveryje.

Mūsų atveju programa mysql kuri vykdoma vartotojo mysql vardu, sunaudoja 53 procentus CPU resurso.

Ką daryti jei serveryje veikianti aplikacija pradėjo naudoti itin daug CPU resurso?

a. Nustatyti būtent kokia aplikacija išnaudoja CPU resursą;
b. Aplikaciją optimizuoti ar sukonfigūruoti geresniai dedikuoto serverio resursų eksploatacijai:
MySQL - konfigūracijos/optimizacijos gidas
Apache - konfigūracijos/optimizacijos gidas
c. Serverio resursų didinimas esant poreikiui (dedikuoto serverio plano didinimas)

2. Padidėjęs serverio virtualios atminties apkrovimas

Atsiradus dedikuoto serverio sutrikimui dėl aukšto virtualios atminties (RAM) panaudojimo, reiktų nustatyti kas išnaudoja šį resursą. Priežastys galinčios lemtį šį sutrikimą:

* Nepakankamas virtualios atminties (RAM) kiekis, serveryje vykdomoms programoms;
* Staiga padidėjus vykdomų programų skaičiui;
* Dėl nekorektiškai veikiančios (-ų) programos (-ų);

Vykdome komandą top serverio SSH konsolėje (1 punkto pavyzdys). Pateikiama lentelė su realiu laiku veikiančiomis aplikacijomis, pavyzdys:
   PID USER    PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
    9463 mysql   16   0  686m 111m 3328 S   2  60 569:17.64 mysqld
   18749 apache  16   0  140m 134m 1868 S   1  6.6   1345:01 php_defunct
24636 apache  17   0 34660  10m  712 S    0.8  0.5   1195:15 php_defunct
22442 apache  24   0  6048 2024 1452 S    0.8  0.1   0:00.04 php_defunct
Čia:

* MEM: indikuoja dedikuotame serveryje veikiančios aplikacijos RAM sunaudojimą. Kuo šis skaičius didesnis, tuo daugiau aplikacija reikalauja RAM atminties. Jei matote jog šis skaičius itin didelis ties viena iš aplikacijų (pvz.: mysql), tuomet problema mySQL serveryje.

Tam jog peržiūrėtumėte laisvos virtualios atminties kiekį, įvykdykite komandą SSH konsolėje:
free -m
Jums bus pateikta lentelė su duomenimis, pavyzdžiui:
total            used              free         shared    buffers     cached
Mem:          4096        415       3680          0          0          0
-/+ buffers/cache:        415       3680
Čia:

* total: iš viso alokuotos atminties kiekis dedikuotam serveriui. Šis kiekis išreiškiamas Megabaitais (MB).
* used: naudojama atmintis.
* free: laisva, galima panaudoti atmintis.

Ką daryti jei serveryje veikianti aplikacija pradėjo naudoti itin daug RAM resurso?

a. Nustatyti būtent kokia aplikacija išnaudoja RAM resursą;
b. Aplikaciją optimizuoti ar sukonfigūruoti geresniai dedikuoto serverio resursų eksploatacijai:
MySQL - konfigūracijos/optimizacijos gidas
Apache - konfigūracijos/optimizacijos gidas
c. Serverio resursų didinimas esant poreikiui (dedikuoto serverio plano didinimas)

3. Serverio klaidos žurnalai.

Tam jog lokalizuoti dedikuoto serverio problemą, reiktų peržiūrėti aplikacijų ar paties serverio generuojamus klaidos žurnalus. Bendruoju atveju klaidos žurnalai saugomi aplanke /var/log . Šiame kataloge galite rasti daugelio programų klaidos žurnalus, pavyzdžiui:

* Apache
* MySQL
* Postfix
* Java

Pastaba: norint įjungti lėtų užklausų dokumentavimą MySQL sistemai, reiktų atitinkamai papildyti my.cnf failą šiuo įrašu (papildžius būtina perkrauti mysql serverį):
log-slow-queries

4. Išaugusios disko vietos sąnaudos/Inode kiekis.

Reikia surasti daugiausiai vietos serveryje užimančius ir didžiausią failų kiekį turinčius katalogus. Daugiau informacijos apie tai galite rasti šiame straipsnyje:

"Disko vietos sąnaudų nustatymui skirtos komandos/įrankiai"
Pažymėtos temos:
Norėdami palikti komentarą, turite prisijungti arba registruokis.
Dedikuoti.lt
Šiame forume rasite informaciją kaip atlikti serverio administravimą, konfigūravimą, įvairių tarnybų bei papildomų aplikacijų diegimą. Taip pat pateiksime rekomendacijų, skirtų serverių saugumui, monitoringui ir optimizavimui. Kviečiame prisijungti prie dedikuotų serverių administratorių bendruomenės, dalyvauti diskusijose ir praplėsti savo žinias serverių administravimo srityje!
© 2007 - 2023 Dedikuoti.lt forumas, visos teisės saugumos.