Uusi palvelin

[weatherc]

cPanelin supportti kävi pikkasen tutkimassa mitä voisi olla syypää tuohon piikkiin...Sinänsä ei tuonut uutisia mutta kylläkin vahvisti epäilyni.

1. Mitä todennäköisemmin minkään sivun skripti EI ole se pääsyyllinen. Apachen tökkiminen oli mitä todennäköisemmin vain seuraus tuosta piikistä/IO-waitistä.
2. Sen sijaan yleisellä tasolla purkilla on suuri IO-aktiviteetti (kovolle kirjoittamista). Sinänsä tämä ei ole uutinen, NWN:än masterit hakkaa mysliä aika kunnioitettavasti, NSD-tutkien kuvien teko, erilaisten muiden kuvien teko, OpenGrads/Mapnik-softat, sekä se fakta että sivujen sisältö on reaaliaikasta ylipäätänsä ja siten filut päivittyvät erittäin tiheään.
3. 15:10 alkaen oli Mapnik käynnisssä tekemässä GFS-ennustehässäkän tiilejä. Kokeiluna tuo 15:10 ajo on huomenna tunti aikasemmin.

Eli, yskiselitteisesti, meillä on tullut SATAII-levyjen IO-raja vastaan.
Eli kuten aavistelin jo alunperin, kovojen suorituskyky loppuu ennen CPU/RAM:ia.
Näin. Piti tämäkin päivä nähdä.

Entä nyt?
Hyvä kysymys mutta tarvittais todennäköisesti yksi parempi "levy" tyyliin SSD tai RAMdisk jonne ohjata nuo IO-intensiivit osat TAI kylmästi alkaa siivous purkilla mitä sillä tehdään ja ei tehdä ja silloin joutaa mm. zoomattavat ennustekartat vääjämättä roskiin...

[systeemi]

Joo en tule olemaan kehityksen jarruna... Eli minun puolesta sellaista rautaa lisää kuin "rautakaupasta" saa. Itselläni puuttuu vielä kaikki mysql ja cronilla ajastetut hässäkät, joten kuormaa on tulossa lisää. _{Jupinaa kun saattaa olla vielä joku päivä syyllinen palvelimen vaikeuksiin}

[weatherc]

Yks loadeja/IO:ta nostattava prosessi on myös RAID-check/synkkaus, se oli eilen käynnissä ja tällä kertaa kesti reilun vuorokauden. Se on ajastettuna oletukena alkaa joka la-su-yö.
Vanhalla dedillä se nostatti loadeja noin 1:llä ja sama näyttää olevan uudellakin, kun se vissiin sai hommansa vihdoinkin päätöksiin tänä aamuna oli loadit tippuneet siihen 1 korville.

Eli minun puolesta sellaista rautaa lisää kuin "rautakaupasta" saa.

Yks vika on että noilla palvelintaloilla ovat hinnat "kohdillaan" lisäraudassa. SSD-levy Hetznerillä kustantaa 30€/kk, phewww...noh, jostainhan niidenkin on sitä rahaa tehtävä...
Pitää fudeerata mikä olisi paras vaihtoehto tuohon, mieleen tullut: (a) SSD-levy lisänä (b) VPS kaveriksi (c) purkki jossa SSD oletuksena. Jokaisella noista on omat huonot ja hyvät puolensa jo ilman tarkempaa miettimistäkin.

Pitää myös ihan varmistukseksi ajaa smartctl:än long testi ihan vaan varmistaakse ettei koko homma ole failaava kovo...

[khyron]

Jos muistia on vielä vapaana ni eikö olis helpointa laittaa sitä kakuksi riittävästi?

[weatherc]

Jos muistia on vielä vapaana ni eikö olis helpointa laittaa sitä kakuksi riittävästi?

Se on yksi vaihtoehto (joka jäi uupumaan äskeisestä)
Muistia on vapaana n 12G tällä hetkellä.

- Myslin, Nginxin, php eacceleratorin tmp:it ovat jo nyt ramdiskillä sekä php:n sessionit memcachessa.
- Koska mysliä hakataan aika kunnioitettavasti (mysqltunerin mukaan 38M queryä reilussa 3 päivässä) se olisi yksi joka varmaan hyötyisi nopeammasta levystä, ramdiskissä on vaan se vika että data katoaa JOS jotain sattuu ja purkki menee alas. Eli sen tarvis kuitenkin backupata kovolle ajastuksella jatkuvasti. Myslin koko on vajaa 1G tällä hetkellä. Sen ilmoittama "max memory usage" nykyasetuksilla on 6.6G
- Sitä ramia tarvitaan kun iskee ruuhkaa sivuille (Apachehan osaa sen ramin popsimisen) eli kaikkea ei voida käyttää ramdiskinä. Nyt en tarkkaan muista kuin paljoa sitä oli käytössä kesän (ainoan) kunnon ukkosruuhkan aikana muuta kun että yli puolet vanhan dedin ramista eli yli 4G.
- esim karttahässäkän tiilet tarvii 2G+ tilaa sekä saman verran lisää niiden tarvitsemat shapefilet, Mapnikin muut datafilut 1G:n verran
- karttatiilien ym. kuvien sun muiden nopeasti päivittyvien filujen siirrossa ramdiskille en näe sinänsä ongelmaa, jos purkki menee alas ne katoaa ja uupuisi kunnes tuoreet ajot/FTP-uppaukset tehty.
- kysymys lienee myös että kuinka paljon IO:ta esim Mapnik softa tarvii noin yleisesti kuvien kirjoittelun lisäksi.

[khyron]

En kyl myslikantaa lähtis ramdiskille tallettaan, vaan lisäisin myslin kakkua sen verran et koko kanta mahtuu sinne, kun se todennäkösesti rikkoo jotain jos käynnissä olevan kannan tiedostoja kopsitaan toisaalle. Olettaen että enimmäkseen luetaan?

Staattiset kuvat olis helpointa laittaa ramdiskille, samaten sellaiset kuvat mitkä generoidaan usein.

[weatherc]

En kyl myslikantaa lähtis ramdiskille tallettaan, vaan lisäisin myslin kakkua sen verran et koko kanta mahtuu sinne, kun se todennäkösesti rikkoo jotain jos käynnissä olevan kannan tiedostoja kopsitaan toisaalle. Olettaen että enimmäkseen luetaan?

mysqltunerin mukaan 90% luentaa 10% kirjoittamista.
Tiedätkö mikä my.cnf:in asetus sopii tuohon?
Tällä hetkellä tmpdir on /dev/shm:ssä joka 7G:n tmpfs, muut polut oletuksessa.

Staattiset kuvat olis helpointa laittaa ramdiskille, samaten sellaiset kuvat mitkä generoidaan usein.

Se on totta. Ongelma on lähinnä se että niitä on jokaisella domainilla kuten NSD:n tutkakuvat eli ei ole yhtä yksittäistä kansiota jota siirrellä...

[weatherc]

cpanelin aspa kävi tutkailemassa lisää....

- Kovot OK smartctl:än mukaan
- Suurin loadin tekijä IO-wait
- Tämä lause kertoo aika lailla koko asian: That is an incredibly large amount of activity for standard sata2 disks

On nyt pari seurantaa käynnissä jotka myös kirjoittavat löydöksensä lokiin kuten iotop ja iostat.

Seurasin iostat:a kotvasen näin "normaaleina" minuutteina jolloin ei noita croneja ajossa.
- yleisesti kärjessä kiikkuu jbd2/md2-8 joka cpanelin aspan mukaan johtuu vain kovasta levy-aktviteetistä, on joku systeemin journaali
- mysliä löytyy liki koko ajan yhden rivin verran, ei sinänsä yllätys
- pure-ftp (IDLE) löytyy useampi ja kaikilla n 4KB/s write, lienee clientraw realtimet jotka pitää yhteyttä auki
- Nginx:ä löytyy useampi

[weatherc]

Mielenkiintoista...Nyt OpenGrads että mapnik ajettu ja logit haettu...
Kummankaan kohdalla ei iotop:in IO liikkunut mihinkään ainakaan noissa logeissa, sen sijaan:
 TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
 600 be/3 root        0.00 B/s   47.08 K/s  0.00 % 99.99 % [jbd2/md2-8]
1081 be/3 root        0.00 B/s    0.00 B/s  0.00 % 88.82 % [jbd2/md3-8]
32361 be/7 root        0.00 B/s   90.23 K/s  0.00 %  0.00 % grads -blc run nordic.gs
Tuossa kohtaa loadit oli 7.

 TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
1091 be/4 root        0.00 B/s   35.26 K/s  0.00 % 55.38 % [kjournald]
1090 be/0 root        0.00 B/s    3.92 K/s  0.00 %  0.15 % [loop0]
29878 be/7 root        0.00 B/s  391.79 K/s  0.00 %  0.00 % python generate_yrtiles.py
29877 be/7 root        0.00 B/s  415.29 K/s  0.00 %  0.00 % python generate_yrtiles.py
Tuossa kohtaa se oli 1.5

Annetaan ohjeeksi seurata tuota iotop:ia ja jos sitä seuraa niin IO-sarakkeen TOP3 ovat jbd2/md2-8, kjournald sekä pure-ftp.

EDIT: Ja tuollainen löytyi:
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
1091 be/4 root        0.00 B/s    3.94 K/s  0.00 % 99.99 % [kjournald]
  600 be/3 root        0.00 B/s    3.94 K/s  0.00 % 99.99 % [jbd2/md2-8]
  555 be/4 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [md3_raid1]
  548 be/4 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [md2_raid1]
Loadit yli 10.

[khyron]

En kyl myslikantaa lähtis ramdiskille tallettaan, vaan lisäisin myslin kakkua sen verran et koko kanta mahtuu sinne, kun se todennäkösesti rikkoo jotain jos käynnissä olevan kannan tiedostoja kopsitaan toisaalle. Olettaen että enimmäkseen luetaan?

mysqltunerin mukaan 90% luentaa 10% kirjoittamista.
Tiedätkö mikä my.cnf:in asetus sopii tuohon?
Tällä hetkellä tmpdir on /dev/shm:ssä joka 7G:n tmpfs, muut polut oletuksessa.

Siitä on ny hetki kun myslin kanss pelasin, eikä sekään ollu niin hirveesti, etten ny ulkoa muista. Mutta http://www.fromdual.com/mysql-database-health-check toi olis varmaan hyvä paikka alottaa.

Staattiset kuvat olis helpointa laittaa ramdiskille, samaten sellaiset kuvat mitkä generoidaan usein.

Se on totta. Ongelma on lähinnä se että niitä on jokaisella domainilla kuten NSD:n tutkakuvat eli ei ole yhtä yksittäistä kansiota jota siirrellä...

Jaa-a, sit pitäs varmaan kattoa jotain apachen mod_cachea tms.