Dedikuoti serveriai, VDS hostingas, debesų kompiuterija
Interneto vizija
Karjera El. paštas

Grįžti   Dedikuoti.lt forumas > Bendruomenės diskusijos > Pamokos > Tipinės problemos

 
 
Temos įrankiai Ieškoti šioje temoje
  #1  
Senas 2012-01-09, 16:21
IV_RomanL avataras
IV_RomanL IV_RomanL neprisijungęs
Interneto vizija
 
Prisiregistravo: 2011 11
Vieta: Vilnius
Žinutės: 640
Arrow Dedikuoto serverio problemų diagnozė

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ą:

Kodas:
top
ir tuomet nuspauskite klavišus SHIFT + M

Prieš jūsų akis turėtų būti pateikta grafa, pavyzdys:
Kodas:
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ė:

Kodas:
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ė:
Kodas:
   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:

Kodas:
   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:

Kodas:
free -m
Jums bus pateikta lentelė su duomenimis, pavyzdžiui:

Kodas:
             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į):

Kodas:
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"

Paskutinį kartą redagavo IV_VygandasS : 2013-08-06 16:54 Priežastis: Pridėtas 4 skyrius "Išaugusios disko vietos sąnaudos/Inode kiekis."
 

Žymės
apache, luzta serveris, my.cnf, mysql, operacinės sistemos, php, serverio darbo problema, serverio strigimas, ssh

Temos įrankiai Ieškoti šioje temoje
Ieškoti šioje temoje:

Detali paieška

Žinučių rašymo taisyklės
Jūs negalite kurti naujų temų
Jūs negalite rašyti žinučių
Jūs negalite įkelti failų
Jūs negalite redaguoti savo įrašų

BB kodas yra Įjungtas
Šypsenos yra Įjungtas
[IMG] kodas yra Įjungtas
HTML kodas yra Išjungtas

Greita navigacija

Panašios temos
Tema Temą sukūrė Forumas Atsakymai Paskutinė žinutė
Fizinio dedikuoto serverio naudojimosi instrukcija. IV_LinasJ Archyvas 0 2015-06-19 10:34
Dedikuoto serverio image'as chasm Klausimai, pastabos, pasiūlymai 5 2013-06-07 18:15
Neišsiunčia laišku iš dedikuoto serverio parfumshop Pagalba 0 2012-12-11 02:56


Visi laikai yra GMT +3. Šiuo metu yra 07:30.


Powered by vBulletin®
Copyright ©2000 - 2019, vBulletin Solutions, Inc.