lauantai 1. helmikuuta 2014

ICT4TN003-12: Linux-palvelimen kuormittamista

Tällä kertaa harjoitellaan koneen kuormituksen ja tilan arviointi. Läksynä on viisi tehtävää, joista ensimmäinen on kuormitustietojen kerääminen munin-ohjelmalla. Koneena edellisestä tehtävästä tuttu HP-harjoituskone, jossa AMD Sempron LE-1300 -prosessori ja 1,8 gigatavua muistia sekä viime viikon tehtävässä asennettu LAMP.

Aloitetaan asentamalla munin:

sudo apt-get install munin

munin-check

Tämän jälkeen tulee useita virheilmoituksia tiedostojen ja kansioiden vääristä omistusoikeuksista. Korjaan ne käsin yksi kerrallaan, jonka jälkeen testaan muninia Firefoxin kautta osoitteessa localhost/munin. Ja sehän toimii!



Sitten stressaamaan!

sudo apt-get install stress

Päätän aloittaa prosessorilla:

stress -c 1

top näyttää, että vahnha prosessori on kovilla:



Testataan seuraavaksi muistin kuormittamista komennolla joka käynnistää neljä prosessia, jotka kukin vievät 256 megatavua muistia:

stress -m 4



Kuten kuvasta näkyy muistin rasittaminen aiheuttaa huomattavaa rasitusta myös prosessorille. Kokeillaan viimeiseksi kovalevyn rasittamista seuraavalla komennolla. Tässä yhteydessä on syytä varmistaa, ettei käytä kaikkea jäljelläolevaa levytilaa, eli kannattaa ensin varmistaa (df -h) vapaana olevan tilan määrä.

stress -d 1

Tämä ei aluksi onnistunut (virheilmoituksena "permission denied"). Google-haku osoitti, että muilla on ollut vastaava ongelma ja se ratkeaa yksinkertaisesti antamalla komento sudo:na:

sudo stress -d 1

Tällä kertaa käytin monitorointiin iotop-ohjelmaa:



Loppuhuipennuksena vielä 90 sekunnin yhteisrasitus:

sudo stress -c 1 -m 4 -d 1 -t 90s



Testien jälkeen muninin keräämissä kuvaajissa näkyy jo jotain elämää, mutta koska aika-akseli on lyhimmilläänkin (päivä) niin pitkä, on tietojen tarkempi tarkastelu hyvin vaikeaa. Siirrytään siis viimeiseen tehtävään ja katsotaan, jos se aikana muniniin kirjautuisi jotain käyttökelpoisempaa.

Ja yksinkertainen esimerkki lokeista. Apachen lokitiedostojen reaaliaikainen seuraaminen onnistuu komennolla:

tail -F /var/log/apache2/*log

Seuraavassa kuvassa näkyy kolme tapahtumaa. Ylimpänä näkyy, että kello 12.05.21 on otettu yhteyttä osoitteesta 192.168.100.23. IP-osoitteen jälkeen tulevat kaksi viivaa tarkoittavat, ettei yhteydenottajasta ole tarkempia tunnistetietoja (RFC 1413 ja HTTP Authentication).



Sen jälkeen tulee päivämäärän ja kellonajan sisältävä timestamp. Seuraavaksi on vuorossa yhteydenottajan antama vaatimus halutuista tiedoitsa, eli tässä tapauksessa halutaan näkyviin "juuri" tai etusivu (/) käyttäen HTTP-protokollaa.

Seuraavat numerot (304 ja 210) ovat HTTP-koodit, joista ensimmäinen kertoo, että kyseessä on muokkaamaton sivu ja jälkimmäinen ilmeisesti sen, että yhteys on muodostettu uudelleen, mitä ikinä se tarkoittaakaan.

Loppuosa on sen verran omituinen, etten osaa sanoa, miksi siinä mainitaan käyttämäni Chromen lisäksi Mozilla ja Windows NT. Ilmeisesti kyse on siitä, että selain ei kerro ainoastaan mikä se on vaan myös mille eri selaimille sopivia muotoiluja se ymmärtää.

Kuvan toinen ja kolmas rivi liittyvät samaan yhteydenottoon. Yritin iPhonellani avata tiedoston /pitsa.html, jota (kuten hyvin tiesin) ei serverillä ole. Kakkosrivin tiedot ovat error.log-tiedostosta, josta näkyy, että osoitteesta 192.168.100.28 tehtyyn yhteydenottoon on jouduttu vastaamaan "File does not exist". Viimeinen rivi on saman tapahtuman kirjaus access.log-tiedostossa. Se on muuten vastaava kuin ensimmäinen pöytäkoneeltani sivuston juureen otettu yhteys, mutta HTTP-koodit ovat toiset: 404 (file not found) ja 502 (bad gateway).

Käydään lopuksi vielä kurkistamassa, miltä munin näyttää:


Suurta eroa kuormitustestin ja muun käytön ei pääsääntöisesti näy, tai sitä ei pysty näin epätarkassa tarkastelussa näkemään. Prosessorin käyttöasteessa näkyy sentään selvä ero, sillä vihreä "järjestelmäkäyttö" on ollut korkeimmillaan juuri silloin, kun ajoin stress-testejä.

Lähteet:

Ei kommentteja:

Lähetä kommentti