30.1.2014
Jätä kommentti
Kirjoittanut ylivaltiatar Ei kategoriaa

Linuxin rasitustestaamista ja lokien selaamista

 Tehtävänanto:

”h2:
– Kerää kuormitustietoja munin -ohjelmalla
– Kuormita konetta stress:llä
– Käytä tunnilla käytyjä työkaluja arvioidaksesi kuormitusta: cpu, mem, io…
– Lopuksi analysoi munin keräämiä käyriä
– Aiheuta valitsemaasi lokiin muutamia rivejä ja analysoi niistä 2-3 riviä perusteellisesti”

Klo 1915

Käytin kotitehtävän testaamiseen olohuoneemme Linux konetta

Ubuntu 12.04.4 LTS

koneen tiedot

prosessori AMD Athlon 64 x Dual Core Prosessor 6000+

Muisti 4GB

Näytönohjain ATI Radeon HD 5700 Series

Aloitin ensin perinteisellä,  eli asensin ensin uusimmat paketit

$ sudo apt-get update

tämän jälkeen asensin uusimmat päivitykset

$ sudo apt-get upgrade

kone ei hakenut jostakin syystä ekalla kertaa päivityksiä, toisella kertaa kun laitoin komennon niin päivitykset asentuivat normaalisti.

kolmannella tarkituskerralla näytönohjaimen ajurit jäivät odottamaan päivitystä.

Varsinaisen tehtävän aloitin asentamalla munin-ohjelman komennolla

$ sudo apt-get install munin

Ohjelma asentui onnistuneesti.

Seuraavaksi asensin stressin

$ sudo apt-get install stress

Tämän jälkeen suoritin linuxin pyynnöstä pakettien siivousta, poistamalla vanhat aiemmin automaattisesti asennetut ja nykyään tarpeettomat “linux-headers-3.2.0-55 linux-headers-3.2.0-55-generic” komennolla

$ sudo apt-get autoremove

paketit poistettiin automaattisesti.

Seuraavaksi asensin iotopin, htopin ja nmonin komennolla

$ sudo apt-get install iotop htop nmon munin

ohjelmat asentuivat onnistuneesti.

 Valitettavasti munin ei lähtenyt pyörimään heti onnistuneesti, joten asensin linuxin kaikki muutkin sen ehdottamat munin-paketit.

Vielä tämänkään jälkeen Munin ei toiminut heti, tämän jälkeen tein munin-checkin, jolloin totesi että oikeudet ovat pielessä. Siirryin var/lib/munin hakemistoon, jouduin menemään sudolla eli

$ sudo su

ja sitten

$ cd /var/lib/munin

Tässä hakemistossa munin-check tuotti herjoja:

/var/lib/munin/munin-graph.stats : Wrong permissions (664 != 644)

/var/lib/munin/munin-update.stats : Wrong permissions (664 != 644)

Muutin oikeuksia ensin chmod-komennolla oikeiksi (ks. yllä) ja sitten omistajuutta joihinkin tiedostoihin chown-komennolla.

Muutosten jälkeen ajoin uudelleen munin-checkin, mutta jostakin syystä munin päällekirjoittaa oikeudet uudelleen väärin. Ilmeisesti munin-cron muuttaa niitä aina kun se kirjoittaa tilastoja, joten jätin nuo kaksi

/var/lib/munin/munin-graph.stats : Wrong permissions (664 != 644)

/var/lib/munin/munin-update.stats : Wrong permissions (664 != 644)

korjaamatta uudelleen tämän jälkeen.

lopetin root session tähän (ctrl+d).

klo 20.15

Säädön ja googlettelun jälkeen päädyimme sivuille(www.debuntu.org/how-to-monitoring-a-aserver-with-munin/) jonka ohjeiden mukaan lähdimme suorittamaan. Tutorini kanssa seuraamaan tämän linkin ohjeita, mutta koska ohjeet osoittautuivat liian monimutkaisiksi sain neuvon että sen sijaan helpompaa oli linkittää muninin www-hakemisto apachen www-hakemistoon komennolla

$ sudo ln –s /var/cache/munin/www .

Testasimme tätä selaimessa kirjoittalla selaimen osoitekenttään localhost ja siellä näkyy www-hakemisto, ja se toimii! Munin kertoo graafisesti selaimessa mitä kaikkea koneella tapahtuu.

Siistimme vielä hieman linkitystä vielä komennolla

$ sudo ln –s /var/cache/munin/www /var/www/munin

Nyt näkyy selkeämmin munin-hakemisto www-hakemiston sijaan, jota klikkaamalla saan näkymään eri käyriä kuormituksen suhteen.

Tämän jälkeen ajoin top-komennon seuratakseni tämän hetkistä tapahtuma tilannetta koneella

$ top

Ennen stressiä, täällä ei yllättäen tapahdu juuri mitään. Hyvä niin siis!

$ free –m

Ja vapaan muistin tilakin näyttää hyvältä, mitä nyt näin tarkkailee ennen tuota stressiä siis.

$ sudo iotop –oa

kertoo meille myös että levyn käyttö on lähellä nollaa toistaiseksi

Lopuksi ennen saunataukoa laitan stressitestin pyörimään tunniksi Linuxin tarjoamalla esimerkki komennolla $ stress –cpu 8 –io 4 –vm 2 –vm-bytes 128m –timeout 10s -> 10s muutettiin 1h komennolla

$ stress –cpu 8 –io 4 –vm 2 –vm-bytes 128m –timeout 1h

Klo 21.15-22.00 saunontatauko

Klo 22.10

Ajoin toisesta terminaalista komentoja stressi testin aikana

$ top

Näytti melko erilaiselta, Cpu(s) osiossa näkyy käyttäjän (us) ja järjestelmän (sy) käyttö jakaantuvan melkoisen tasan, kummassakin poukkoillaan jonkin verran mutta keskimäärin käyttä jakaantuu noin 50-50.

En selkeästi laittanut kauhean kovaa stressitestiä päälle, mutta ero on silti havaittavissa muistinkäytössä stressin aikana. Silti firefoxi käyttää enemmän muistia kuin stress tällä hetkellä.

Load average oli selkeästi korkeammalla stressitestin ajan, tosin koska stressi aika oli  yksi tunti, niin se laski sitä suhteellisen hitaasti.

Stressin valmistuttua päätin ajaa vielä toisen mutta lyhyemmällä ajalla sekä pienellä muutoksella muistinkäyttöön.

$ stress –cpu 8 –io 4 –vm 2 –vm-bytes 1280m –timeout 1m

Muistin määrän nostaminen lisäsi merkittävästi muistin käytön määrää, sen sijaan että luvut olivat aiemmassa testissä luokkaa (%MEM) 4.5, olivat ne nyt 30.2 jne.

Kokeilin myös komentoa

$ htop

Joka näyttää hieman erilaisella tyylillä mitä koneella tapahtuu.

Tässä välissä kävin myös vilkaisemassa selaimen puolella, mitä muni puuhailee ja piirustelee siellä.

Kuten kuvassa näkyy, niin vastaanotettuja paketteja on enemmän, koska käytännössä mitään ei ole oikeastaan lähetetty ulos. On vain vastaanotettu paketteja koneen päivitystä varten.

Kuten kuvasta näkyy vasemmassa laidassa alhaalla, on yksittäisiä keskeytyksiä monen laisia.

Pata-amd

on levyohjain, jonka keskeytyksiä käsitellään eniten koko listauksesta. Hyvänä seuraajana tulee

fgrx[0]@PCI: 2:0:0

joka kertoo näytönohjaimen tilanteesta keskeytysten suhteen, eth0 sitten taas kertoo meille verkon tilanteesta keskeytysten suhteen. Käytännössä tämä kaavio kertoo miten laitteet keskeytyksellä kertovat mitä haluavat tai että ovat saaneet työnsä päätökseen. Ikään kuin oppilas viittaa tunnilla tietävänsä vastauksen ja opettaja käsittelee viittaajat (mahdollisesti) järjestyksessä.

Apachen puolella munin käyrät eivät paljoa sattumia tarjonneet, mutta noin yleisesti näen kyllä miksi munia käytettäisiin. Se tarjoaa kuitenkin selkeät piirtokäyrät päivälle, viikolle, kuukaudelle ja vuodelle, joka on mielestäni melko mahdikasta. Esimerkiksi jos serverillä on paljon liikennettä tai jos esimerkiksi Apache vie leijonanosan serverin resursseista ja/tai tilanne alkaa olla sellainen että palvelimen kuormitus liian tiukoilla.

Tai sitten useamman serverin tilanteessa seuraamaan mikä on yleinen liikenne servereillä, jos kolmella neljästä on väljää ja neljännellä käyrät hyppivät korkealla, voit saman tien alkaa miettimään korjaustoimenpiteitä tilanteen suhteen, esimerkiksi siirtää tietokantoja serveriltä toiselle jos ne kuormittavat serveriä liikaa. Tämä kaikki tietenkin aina vähän tilanteesta riippuen.

Klo 23.14 tehtävä jatkuu myöhemmin.

To klo 22.10

Tehtävän lopuksi pyydettiin aiheuttamaan valitsemaani lokiin muutamia rivejä ja analysoimaan niistä 2-3 riviä perusteellisesti.

Tein slogger nimisellä ohjelmalla merkintöjä syslogiin, mutta niissä ei ollut sen kummempaa analysoitavaa, tekemäni merkintä näkyi aikaleimoineen ja tekijä (kisu, eli minä ja logger) näkyi lokeissa sekä tietysti koneen nimi (belladonna). Ensimmäinen testi komento oli

$ logger system rebooted

Joka näkyi minun tekemänäni lokeissa, toinen komento oli

$ logger –n localhost system rebooted

joka sitten näkyi lokeissa loggerin tekemänä.

Tämän jälkeen lähdin hakemaan lokeja joista löytyisi merkintöjä: Severity levelistä, Keywordista ja Descriptionista. Siirryin tutorin ohjaamana /var/lightdm hakemistoon, joka oli ensimmäinen josta löytyi edes jotain kriittisiksi merkittyjä. Lokeista löytyi hienosti ääripäät Debugista Criticaliin.

Lokit:

[+3,41s] DEBUG: background.vala:67: Making background /usr/share/backgrounds/The_Grass_aint_Greener_by_fix_pena.jpg at 1360×768

[+3,41s] DEBUG: background.vala:144: Error loading background: Tiedoston ”/usr/share/backgrounds/The_Grass_aint_Greener_by_fix_pena.jpg” avaus epäonnistui: Tiedostoa tai hakemistoa ei ole

[+3,41s] DEBUG: background.vala:116: Render of background /usr/share/backgrounds/The_Grass_aint_Greener_by_fix_pena.jpg complete

[+3,41s] CRITICAL: background_loader_create_pattern: assertion `image != NULL’ failed

Tässä kohtaa lokiin on kirjattu DEBUG merkintänä miten kirjautumisikkunan aliohjelma/metodi/funktiota/wodnot yrittää luoda taustakuvaa kyseisestä hakemistosta. Heti seuraavalla rivillä lukee kuitenkin, ettei taustakuvan lataaminen onnistunut, koska taustakuvaa ei ole olemassa. Sitten 3 rivillä kuitenkin tulee DEBUG ilmoitus että kyseisen taustakuvan renderöinti on valmis, joka sopivasti sotkee heti 4 rivin CRITICAL ilmoitusta vastaan, joka suoraan ilmoittaa että taustakuvan lataaminen ei onnistunut koska ehto ei ole täyttynyt, eli kuvaa ei ole olemassa.

Lähteet:

Jätä kommentti