Palvelimen määräaikanen soppari jossa nordicweather ja kumppanukset majailevat meni umpeen tuossa äskettäin ja tuli aika tiirailla pikkasen mitä Hetznerin listasta löytyy. Tai no, se on ollut tarkkailun alla jo koko vuoden. ;)
Nykyinen dualcore AMD on raksuttanut ihan kivasti (eikä edes mennyt kyykkyyn menneen kesän ainossa kunnon ruuhkasta) mutta niin on Hetznerin valikoimakin mennyt eteenpäin.
Uudessa purkissa on I7 quadcore prossu sekä RAM tuplaantuu 16 G:hen. :)
Tämä mahdollistaa mm. parempien ennustekarttojen teon.
Purkki ollut rakenteilla vajaan viikon ja nyt on aika alkaa siirtelmään sivuja.
Omien sivvujen, ukkostutkat.fi ja nordicweatherin filut on jo siirretty mutta domaineja ei ole vielä. NWN raksuttaa tällä hetkellä sekä uudella että vanhalla purkilla. Näin ollen pitäisi NWN-sivut toimia suht OK myös domainin siirron aikana, tosin voi pientä köhimistä esiintyä.
Ensimmäisenä tulilinjalle joutuu ukkostutkat.fi jonka domain siirtyy tänä iltana. Se toimii samalla koekaniinina että php sun muut toimii OK ja tarvittavat palikat on asennettu.
Mikäli se toimii OK siirtyy nordicweatherin domain tänä yönä (mikäli puskista ei pukkaa ukkosia ;)) ja muiden sivujen siirto voisi alkaa huomisesta alkaen. Ne eivät siirry kertarysäyksellä vaan sitä mukaan kun sivujen ylläpito pystyy muuttamaan DNS:ät sun muut siten että ovat siirretty syyskuun alkuun mennessä jolloin pitää siirtää hallintapaneelin lisenssi jolloin vanhan purkin sivut sammuvat.
(Sivujen ylläpitäjille lähtee YV:tä kunhan saan nuo omat siirrettyä/testattua :))
ukkostutkat.fi siirretty.
Users online-laskuri ei toimi kunnes nordicweather:kin on siirretty, muutoin näyttää toimivan ihan OK, ilman ensimmäistäkään korjausta. :)
nordicweather.net siirretty.
Pari kuoppaa oli matkalla kun olin unhotanut kopsata subdomainien Nginx-konffit muutoin näyttää menneen ihan mallikkaasti.
Tuore wxsim-ennuste tulee ihan just kohta ja GFS-kartat tuossa parin tunnin päästä :)
Domainin propagoimiseen meni täällä alta vartin että molemmat purkit löysi perille ;D
No onhan ainakin ollut kiire iltapuhde ;)
Ja tervehdys, on eka postaukseni tänne, enkä voinut vastustaa "kiusausta" :D
/eno
Sent from my iPad using Tapatalk HD
Tervetuloa foorumille :)
LainaaNo onhan ainakin ollut kiire iltapuhde
No ei se mikään kovinkaan kiireinen ollut ;)
Ennusteet ja GFS:ät tulevat automatiikalla ajastuksella ja domainin suhteen piti vai muuttaa parit numerosarjat jotta löysi perille uudelle serverille :P
Palvelin näyttäisi olevan alhaalla tällä hetkellä, sillä mitkään sivut eivät vastaa. Vika alkoi todennäköisesti aivan hiljattain, sillä olen nyt aktiivisesti ollut sivuilla, sillä teen yhtä juttua joka ei onnistu ilman sivujen kahlaamista. Osaatko weatherc sanoa johtuuko tämä Hetznerin päästä vai jostain muusta syystä?
Nyt toimii jälleen :)
Oli parin domainin siirto ja vaikka kuinka koitin kahlata nuo Nginxin konffifilut läpi niin livahti yksi jossa vanha ip-numero.
cpanel kun siirtää domainin uudelleen käynnistää nuo nginxit sun muut aina automaagisesti, tulos oli nähtävissä, epic fail.
Sitten piti vaan löytää se filu eikä nginxin error-viesti, hölmöä kyllä, kerro missä filussa se vika on, kertoo vaan mikä se vika on.
Manuaalisesti jos teen jotain tuollaista niin käytän sen testeriä jossa se testaa että konffit on OK mutta sitä ei tällaisessa automaagisessa siirrossa voi tehdä.
Lisää vauhtia myllyyn ;D
Törmäsin, osin sattumalta, mielenkiintoiseen juttuun nimittäin ramdiskiin. Eli suomeksi RAM:in hyötykäyttö "kovalevynä".
Ramdiskin luku on jutun mukaan jopa 30 kertaa nopeampaa kuin kovalevyltä lukeminen joten tähän sopisi esim tmp-data tai muu data joka päivittyy useasti/luetaan usein.
Uudella purkilla on 16G RAM josta ~2G käytössä joten giga pari voisi mielestäni hyvin käyttää tähän mikäli keksii hyvää kohdetta. :)
Ensimmäisenä siirettiin Nginxin cache sinne viime yönä ja tänään meni myslin tmp-ostasto, molemmat meni /dev/shm:ään :)
Homma tietenkin seurannassa ettei karkaa lapasesta koko homma :)
Testissä on myös 10MB palikkana NSD:n cachekansio josta oman tutkan NexStorm-tabin kuvan sekä timelapse-kuvat tulevat.
Koska ramdiskin koko pitää määrittää etukäteen, eikä turhan isoa saa asettaa niin tuo 10 MB kuullosti sopivan pieneltä (nuo kuvat ovat 4MB) ja siihen saisi vielä hyvin esim AJAX:lla päivittyvät NS-filut sekä clientraw-filut mahtumaan.
Jälleen kerran Linukka voittaa helppoudellaan Wintoosan 100-0 tässä(kin) asiassa :)
On nyt muutamana päivä ollut jotain joka aiheuttaa purkin liki totaalisen jumittamisen noin klo 15:04.
Tämä tapahtuu vain tänä aikana, muutoin kaikki OK.
Koitin tänään seurata asiaa (myös cpanelin aspa on tietoinen siitä) ja
- se alkoi noin 15:04
- loadit räjähti katosta ulos yli 35:en :o
- loppuu muutamassa minuutissa
- se mitä sain siitä ulos on Apache joka sekoaa -> joku php-skripti aiheuttaja (ei cronilla ajettava sellainen) ?
- tuona aikana EI ole mitään GFS- yms häkkyrää ajossa
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...
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
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.
LainaaEli 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...
Jos muistia on vielä vapaana ni eikö olis helpointa laittaa sitä kakuksi riittävästi?
Lainaus käyttäjältä: khyron - maanantai, 03.09.2012, 11:57
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.
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.
LainaaEn 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.
Lainaa
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ä...
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
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.
???
Lainaus käyttäjältä: weatherc - maanantai, 03.09.2012, 15:07
LainaaEn 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.
Lainaa
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 (http://www.fromdual.com/mysql-database-health-check) toi olis varmaan hyvä paikka alottaa.
Lainaus käyttäjältä: weatherc - maanantai, 03.09.2012, 15:07
Lainaa
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.
Etenee...:)
Baseloadit ovat ihan OK tällä hetkellä tippuen jopa 0.5 korville aina välilä mitä ei olla nähty aikoihin :)
Oma arvio on että tämä sama "ongelma" oli jo vanhalla dedillä. Se ei vaan ollut niin näkyvä koska siinä oli enemmän CPU-pohjaista hidastumista kun hakkasi 100%:a jatkuvasti. Nytten harvoin päästään edes yli 25% CPU-käytön, oikeastaan vain OpenGrads,Mapnik sekä cpanelin jotkut ajastetut toiminnot kuten backuppi onnistuvat siinä.
Hetznerillä on, kappas vaan, "upgrade lista", eli laitetaanpa lisää RAM:ia koneeseen niin saadan rauhassa väsätä ramdiskiä :)
Tällöin voidaan laittaa jokaiselle sääasema-domainille myös oma vaikkapa 50MB ramdisk jonne voi tallentaa NSD-kuvat, NS-filut, clientrawt ja muut vastaavat nopeatempoiset filut.
Sen tarkempi asennusajankohta tulee myöhemmin.
LainaaSiitä 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
Mysli on ollut seurannassa koko ajan niin mysqltunerillä että tuning-primer:llä. Tuossahan on se sama vika kun Apachella että mitään suoraa ohjetta ei ole olemasa tyyliin "jos on 16GB RAM + quadcore, laita nämä asetukset" vaan mutu-tuntumalla hommaa pitää ruuvata...
LainaaJaa-a, sit pitäs varmaan kattoa jotain apachen mod_cachea tms.
Kaikki data joka pusketaan selaimelle .php-päätteisenä menee jo nyt Nginxin proxy-cachehen eli niitä ei generoida kuin joka X sekunti maksimissaan. Aika vaihtelee pikkasen skriptistä on haaraukassa 0 sek - 360 sek jossa 20 sek on oletuksena. Nämä NSD-skriptit ovat kuitenkin siitä poikkeavia etteivät puske selaimelle yhtään mitään vaan generoivat X kpl png-kuvaa joka tallentaa levylle kerran minuutissa jos aktiviteettiä.Nämä valmiiit png-kuvat tarjoillaan sitten sivuille pälliseltäväksi Ngnxin toimesta :)
Kuitenkin ne NSD-skriptit jotka ollaan tähän mennessä saatuu koottua bash-filuun ovat paljon kevyemmät ajettavaksi kuin "selaimella"/Apachen läpi kutsutut.
Tänään on sitten vanhan dedin "hautajaiset" kun cpanelin lisensi siirretään uudelle purkille sekä vanhalle dedille ajetaan "käyttiksen uudelleenasennus" jotta meitin data "katoaisi" jonka jälkeen H:n hallintapaneelista painetaan delete. :)
En ole saaut vahvistusta vielä mutta RAM lisäys tilattu klo 23:ksi Suomen aikaa (tai sen jälkeen miten heilee sopii, pystyvät tekeen sen 24/7) jolloin aihettunee pairinkymmenen minuutin breikki.
Vahistus tullut että lisäys tapahtuu tänä iltana klo 23 Suomen aikaa.
Lainaus käyttäjältä: weatherc - tiistai, 04.09.2012, 17:17
LainaaSiitä 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
Mysli on ollut seurannassa koko ajan niin mysqltunerillä että tuning-primer:llä. Tuossahan on se sama vika kun Apachella että mitään suoraa ohjetta ei ole olemasa tyyliin "jos on 16GB RAM + quadcore, laita nämä asetukset" vaan mutu-tuntumalla hommaa pitää ruuvata...
Muistaakseni toi kyl anto ihan ehdotuksia mitä pitää tehdä.
LainaaMuistaakseni toi kyl anto ihan ehdotuksia mitä pitää tehdä.
Sekä mysqltuner että tuning-primer tekee sen juu. Tosin ei niihin sokeasti kuitenkaan voi luottaa koska jotkut ehdotukset saattavat olla yliampuvia purkin resursseihin nähden. Tällä hetkellä näyttää mysli ihan OK:lta ainakin siltä osin, max memory 100:lla yhteydellä siinä 20% korvilla.
Se on lähinnä sitä mieletöntä levylle kirjoittelua jota tarvis saada kuriin pikkasen vaikka Memcacheta käyttäen enemmän kuin nyt. Nytten NWN/yr-tietokanta käyttää sitä lukemiseen kun myös kirjoituspuoli voisi hyötyä siitä. Varsinkin tuo toplista joka hakkaa ennätykset suoraan kantaan arvo kerrallas, ja se vain sen takia että se toimii yksinkertaisesti parhaiten, php-looppi-vertailu jossa kirjoitti tiedot kantaan kaikki kerralla teki vain erroreita kun 9 mukamas oli isompi kun 12 ja muuta yhtä hölmöä...
Lainaa
Vahistus tullut että lisäys tapahtuu tänä iltana klo 23 Suomen aikaa.
Arvioitu downtime on 10-25 min lisäyksen yhteydessä.
Lainaus käyttäjältä: weatherc - keskiviikko, 05.09.2012, 13:18
LainaaMuistaakseni toi kyl anto ihan ehdotuksia mitä pitää tehdä.
Sekä mysqltuner että tuning-primer tekee sen juu. Tosin ei niihin sokeasti kuitenkaan voi luottaa koska jotkut ehdotukset saattavat olla yliampuvia purkin resursseihin nähden. Tällä hetkellä näyttää mysli ihan OK:lta ainakin siltä osin, max memory 100:lla yhteydellä siinä 20% korvilla.
Emmää puhunu niistä vaan tosta fromdualin healtchekistä.
Lainaus käyttäjältä: weatherc - keskiviikko, 05.09.2012, 13:18
Se on lähinnä sitä mieletöntä levylle kirjoittelua jota tarvis saada kuriin pikkasen vaikka Memcacheta käyttäen enemmän kuin nyt. Nytten NWN/yr-tietokanta käyttää sitä lukemiseen kun myös kirjoituspuoli voisi hyötyä siitä. Varsinkin tuo toplista joka hakkaa ennätykset suoraan kantaan arvo kerrallas, ja se vain sen takia että se toimii yksinkertaisesti parhaiten, php-looppi-vertailu jossa kirjoitti tiedot kantaan kaikki kerralla teki vain erroreita kun 9 mukamas oli isompi kun 12 ja muuta yhtä hölmöä...
Yleensä kuitenkin kuormaa saadaan helpoiten karsittua kirjottamalla koodit niin ettei ne tee turhaa työtä, kuin kannan asetuksia viilaamalla.
LainaaEmmää puhunu niistä vaan tosta fromdualin healtchekistä.
Ahaa.
No mut myös nuo yllä mainitut kertoilee kaikelaisia satuja. :)
Lainaa
Yleensä kuitenkin kuormaa saadaan helpoiten karsittua kirjottamalla koodit niin ettei ne tee turhaa työtä, kuin kannan asetuksia viilaamalla.
Toki tottakai mutta oma kokemus esim mylistä on myös että asetuksilla voi olla suurikin merkitys. Jos ovat päin hevonkuusta niin ei slipstriimatuinkaan koodi toimi.
NWN:än kohdalla haut ja kirjoittelut on todella vedetty minimiin jos nyt ei tuota toplistaa lasketa, esim asemien tiedot haetaan kannasta vain kerran tunnissa muutoin on memcachessa oleva data käytössä jne. Pitää myös muistaa se tosiseikka että NWN käsittelee liki 1000 aseman tietoja kun se datafilujas tekee ja sitä säädataa tunnetusti ei oikeen voi cacheta pidemmäksi aikaa kuin asemalta hakujen väliseksi ajaksi jos sen haluaa olevan tuoretta :)
Siinä valossa se skripti toimii oikeen mallikkaasti ja siirto txt-filuista mysliin aikoinas oli paras uudistus mikä sille on tehty, eikä se loadeissa katsottuna mikään järin raskaskaan ole. Kauhistuttaa vaan se mysqlin query-laskurin raksutus joka laukkaa 130 q/s vauhtia :)
LainaaArvioitu downtime on 10-25 min lisäyksen yhteydessä.
Lisää RAMia lisätty myllyyn onnistuneesti ja mylly palasi linjoille 23:22.
Nyt htop softa kertoilee määräksi 31806 MB ;D 8)
Kaikki softatkin näytti pikavilkaisulla olevan käynnissä täysin OK :)