frame
Sveiki apsilankę!
Jei forume lankaisi pirmą kartą, kviečiame registruotis ir prisijungti prie diskusijų.
PrisijungtiRegistruotisSveiki apsilankę!
Jei forume lankaisi pirmą kartą, kviečiame registruotis ir prisijungti prie diskusijų.
Quick Links
Kategorijos
- 843 Visos kategorijos
- 196 Apie paslaugas
- 41 Naujienos bei pranešimai
- 155 Klausimai ir pastabos
- 614 Pamokos
- 17 Tipinės problemos
- 30 Serverių saugumas
- 51 Valdymo pultai
- 25 Web serveriai
- 12 Pašto serveriai
- 14 Monitoringas
- 41 Kitos aplikacijos
- 47 Informaciniai straipsniai
- 358 Pagalba
- 25 Pageidavimai
- 101 Įvairios diskusijos
- 136 Archyvas
Dedikuoto serverio problemų diagnozė
IV_RomanL
Interneto vizija
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ą:
Prieš jūsų akis turėtų būti pateikta grafa, pavyzdys:
Eilutė:
* 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ė:
* 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:
* 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:
* 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į):
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"
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
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
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
* 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
* 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
* 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
total used free shared buffers cached
Mem: 4096 415 3680 0 0 0
-/+ buffers/cache: 415 3680
* 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"
Norėdami palikti komentarą, turite prisijungti arba registruokis.
foot
