Prosessinhallintaa ja lokeja
Aloitin harjoituksen tekemisen n. kello 6.35 / 8.35 ja lopetin n. 7.45 / 9.45.
Harjoitus on osa kurssia http://terokarvinen.com/2020/linux-palvelimet-2020-alkukevat-kurssi-ict4tn021-3010/
Tein harjoituksen omalle palvelimelleni, jolle olin jo aiemmin asentanut sysstatin. Valitettavasti en laittanut ohjelmaa ottamaan historiaa ylös, joten en voi jälkikäteen katsella kuormitustietoja. Tein kuitenkin harjoitusten aikana siinä kyseisen komennon kohdalla kuormitustestauksia.
a) Asenna kuormitusohjelma: sysstat
Komennolla $ mpstat -V näki, oliko sysstat asennettuna. Komennolla $ sar -u -o sarfile 2 5, sar luo sarfile tiedoston siihen hakemistoon, jossa nyt olen. ’-u’ kertoo tietoa CPU:sta 2 sekunnin välein ja 5 raporttia.
b) Kuormita järjestelmän eri osa-alueita.
Käytin tässä stress-ohjelmaa. (ohjeet: https://www.tecmint.com/sysstat-commands-to-monitor-linux/)
- $ stress -c 2 -i 1 -m 1
- ”-c 2 : Spawn two workers spinning on sqrt()
- -i 1 : Spawn one worker spinning on sync()
- -m 1 : Spawn one worker spinning on malloc()/free()”
- (en laittanut komentoa pysätyksylle, joten se pyöri siinä muutaman minuutin, kunnes painoin ctrl + C)
- stress: info: [5196] dispatching hogs: 2 cpu, 1 io, 1 vm, 0 hdd
Avasin toisen päätteen, jotta näkisin, mitä sar sanoo:
(http://sebastien.godard.pagesperso-orange.fr/man_sar.html)
- %user
- percentage of CPU utilization that occurred while executing at the user level (application)
- %system
- percentage of CPU utilization that occurred while executing at the system level (kernel). Note that this field includes time spent servicing hardware and software interrupts
- %steal
- percentage of time spent in involuntary wait by the virtual CPU or CPUs while the hypervisor was servicing another virtual processor.
- %idle
- percentage of time that the CPU or CPUs were idle and the system did not have an outstanding disk I/O request
Eli, mitä se kertoo, on, että User ja System jakoivat CPU:n käytön keskenään stress-testin aikana.
Seuraavaksi katsotaan, mitä ”uptime” komento sanoo (heti stress-ohjelman asennuksen jälkeen ja stress-komennon ajon jälkeen):
Huomaa, että load average on suurempi ajon jälkeen (alempana kohdassa g) analysoin tätä enemmän).
Katsotaan vielä, mitä sar sanoo, kun stress ei pyöri enää (verrattavissa sar kun stress pyörii ja kun se ei pyöri):
Huomaa heti, että CPU on idle eli ei tee mitään.
c) iotop
(lähde: https://www.globo.tech/learning-center/install-iotop-ubuntu-16/ )
“It monitors what input or output is currently happening on your machine, helping you to quickly identify problematic issues of disk usage”
Asensin iotopin ja laitoin sen pyörimään, samalla kun laitoin stress-komennon pyörimään (kuvan oikeassa alakulmassa näkyy komento):
COMMAND-kohdassa näkyy, mitä komentoa cpu suorittaa. Siellä näkyy tuo ”stress”-komento. IO> kertoo koko IO-käytön.
d) dstat
(lähde: https://hostpresto.com/community/tutorials/how-to-install-and-use-dstat-on-ubuntu-16-04/ )
”Dstat is one of the most powerful and flexible utilities for generating and monitoring Linux resource statistics. You can easily view your system resources instantly using dstat.”
Asensin dstatin ja ajoin komennon $ dstat:
Tiedoista huomaa, että cpu on toimeton, network eli verkko lähettää ja ottaa vastaan tietoja (minulla oli monta välilehteä avoinna), ja että disk lukee ja kirjoittaa tietoja välillä.
Laitetaan vähän stressia ja katsotaan uudestaan (alemmassa pääteikkunassa on stress-komento).
- ”If you want to display the information about your cpu, disk (sda2) utilisation and system load, run the following command:”
- $ dstat -cdl -D sda2
dstat:ista huomaa tuon stress-ajon pysähtyminen (kohta, jossa idl-kohta muuttui 0 -> 92 -> 100). Load average myös kolminkertaistui verrattuna aiempaan toimintaan. Tästä näki myös, että user ja system käyttivät molemmat puolet cpu:sta.
e) ss –listening
(lähteet: https://www.linux.com/topic/networking/introduction-ss-command/ ja https://www.binarytides.com/linux-ss-command/)
”The ss command is a tool used to dump socket statistics”. TCP ja UDP ovat protokollia.
$ ss –listening –tcp –numeric
— tcp kertoo tcp-yhteydet
”For example apache web server opens a socket connection on port 80 to listen for incoming connections.”
$ ss –listening –tcp
Erona edelliseen on, että portit kerrottiin numeroina, kun nyt ne on protokollan niminä (eli siis, mille protokollalle kyseinen portti on varattu [niitä on etukäteen päätetty tietty määrä]).
$ ss –tcp
Tämä kertoo, mitä yhteyksiä sillä on. Nuo peitetyt ovat minun internetin ip-osoitteita. 222.186.175.140 on taas China Telecom:in antama ip-osoite.
$ ss –listening –udp
Tämä kertoo, ketkä kuuntelevat udp-lähetyksiä.
f) grep -i error /var/log/syslog; grep -ir error /var/log/
- $ grep -i error /var/log/syslog
- Mar 19 06:44:52 blingi systemd-resolved[27840]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
”This warning is logged by systemd-resolved, whenever a name can not be resolved by the DNS system (e.g. nslookup http://www.kjfoiqaefah34876asdf.com). This can be tolerated and is no reason to be alarmed. This is no error and nothing needs to be fixed.”
Muita erroreita ei tullut.
- $ grep -ir error /var/log
Tämä antoi pitkän listan logeja aiemmilta ajoilta (tässä viimeiset kolme):
- /var/log/apache2/error.log:[Thu Mar 19 07:23:28.235163 2020] [authz_core:error] [pid 30188:tid 139861843470080] [client xxx.xxx.xxx.xx:45402] AH01630: client denied by server configuration: /etc/apache2/\xe2\x80\x9c
- /var/log/syslog.1:Mar 18 14:39:51 blingi systemd-resolved[27840]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
- /var/log/syslog.1:Mar 18 14:40:05 blingi systemd-resolved[27840]: message repeated 2 times: [ Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.]
Aiemmat errorit liittyivät myös apacheen.
g) Load average näkyy esim ’uptime’, ’top’, ’htop’. Prosessoriydinten määrä näkyy ’nproc’. Miten load average tulkitaan? Miksi prosessoriydinten määrä on tässä kiinnostava?
- $ uptime
- 07:28:23 up 34 days, 22:31, 2 users, load average: 0.00, 0.00, 0.16
Tämä kertoo, kuinka kauan palvelin on ollut päällä, kuinka monta käyttäjää sillä on (kaksi, koska minulla on kaksi pääteikkunaa auki) sekä load averagen.
(lähde: https://www.tecmint.com/understand-linux-load-averages-and-monitor-performance/)
”System load/CPU Load – is a measurement of CPU over or under-utilization in a Linux system; the number of processes which are being executed by the CPU or in waiting state.”
”Load average – is the average system load calculated over a given period of time of 1, 5 and 15 minutes.”
Eli:
- load average over the last 1 minute is 0.00
- load average over the last 5 minutes is 0.00
- load average over the last 15 minutes is 0.16
Eli ei paljon mitään ole cpu:n pitänyt tehdä.
Otetaan aiempi tulos vertailuun:
- stress testin jälkeen:
- load average over the last 1 minute is 3.97
- load average over the last 5 minutes is 2.61
- load average over the last 15 minutes is 1.18
Nyt on huomattavasti enemmän äksöniä tapahtunut.
Jos load average on 1, se tarkoittaa, että cpu:ta käytettiin 100 %:sesti keskimäärin. Yksi prosessi pyöri cpu:ssa viimeisen yhden minuutin ajan. Eli nyt cpu oli 297 %:sesti ylikuormittunut: keskimäärin 2,97 prosessia odottivat cpu:n vuoroa viimeisen minuutin aikana.
Komennolla $ nproc näkee, kuinka monta prosessiydintä palvelimella on (tässä tapauksessa vain 1). Miksi niiden määrä on kiinnostava? Koska yksi cpu pystyy suorittamaan vain yhtä tehtävää kerralla. Eli mitä enemmän cpu:lla on tehtäviä, sitä kuormittuneempi se on (ellei sillä ole tarpeeksi ytimiä, jotka suorittavat niitä).
h) Analysoi lopuksi koko ajalta keräämäsi kuormitustiedot. Löydätkö esimerkiksi aiheuttamasi kuormituspiikin?
- $ sar -r -s 06:38:00 -e 07:40:00
- tämä komento antaisi sar tiedot tuolta ajanjaksolta
- Cannot open /var/log/sysstat/sa19: No such file or directory
😦
Otin kuitenkin kuromitustietoja jokaisen osion yhteydessä, joten toivon niiden riittävän.
Emman Linux-kurssin blogi 