Uusien kätköjen valvontajärjestelmän uusi kehitysversio on otettu käyttöön.
Tavoitteena oli paikata geocaching.comin ongelmat apidataliitynnän nopeuden suhteen. Apidataliityntä on ajoittain niin hidas että normaaliin pyyntöön tietyn pisteen ympäristön kätköistä on välillä vastaus viipynyt jopa minuutin Etelä-Suomen runsaiden kätköalueiden osalta. Niinpä koko Suomen kattava 10 pisteen tarkastus on vienyt jopa 5 minuuttia.
Ongelma aiheutti myös 6.8.2010 klo 23:55 ilmoitetun ongelman jossa uusien kätköjen mukaantulossa palveluun oli satunnaisen mittaisia viiveitä koska prosessien maksimiajoajat täyttyivät. Tällöin geocaching.comin apidataliityntä oli täysin käyttökelvoton ja sama alkoi ilmenemään myös tänä iltana. Niinpä uusi kehitysversio täytyi näpytellä kasaan nopeasti ja laittaa pyörimään. Tämäkään versio ei poissulje mahdollisia uusien kätköjen havainto-ongelmia tilanteissa joissa apidataliityntä lamaantuu täydellisesti mutta pystyy kuitenkin hoitamaan hommia näköjään vakioksi muodostuneiden viiveiden kera.
Uusi versio käynnistää kaikki 10 pisteen tarkastukset yhtä aikaa rinnakkaisiin prosesseihin. Tällöin tarkastustapahtumat saadaan läpi enimmillään noin minuutissa ja samalla järjestelmä on huomattavasti vikasietoisempi koska yksittäisen pisteen pyynnön hitaus taikka epäonnistuminen ei aiheuta muiden pisteiden osalta hitautta taikka estä niiden pyyntöjä. Oletettavasti uusi (raskaampi) tapa ei kuitenkaan aiheuta kuormitusongelmia geocache.fi:n suhteen mutta seuraan tilannetta.
Koska kyseessä on jälleen merkittävä muutos on myös ongelmat mahdollisia. Prosessiseuranta on itselläni pyörimässä ja uusi järjestelmä on onnistuneesti jo 4 uutta kätköä havainnut ja muutenkin toimii odotetusti mutta silti kaikki on teoriassa mahdollista. Uskoisin kyllä ettei mitään ongelmia ilmene mutta jos olen väärässä niin pahoittelen jo etukäteen asiaa!
Uusien kätköjen valvontajärjestelmä
Uusien kätköjen valvontajärjestelmä
7.7.2018 jälkeen kirjoittamani viestit olen kirjoittanut yksityishenkilönä ja kätköilijänä "haksu10", en sivustoon liittyvänä taikka sen ylläpitäjänä.
Kyseistä päivämäärää edeltävät viestit voivat olla sivustoon liittyviä ylläpidollisiakin viestejä.
Kyseistä päivämäärää edeltävät viestit voivat olla sivustoon liittyviä ylläpidollisiakin viestejä.
Re: Uusien kätköjen valvontajärjestelmä
Saako udella, minkälaista rautaa, millaisilla loudeilla? Räkki vai torni?
Re: Uusien kätköjen valvontajärjestelmä
Voi kun taas muistaisi mitä nämä koneet olivatkaan...Seq kirjoitti:Saako udella, minkälaista rautaa, millaisilla loudeilla? Räkki vai torni?
Jotain räkkipalvelimia nämä ovat, jotka kertovat että professorina on Intel(R) Xeon(TM) CPU 3.06GHz (eli neliytiminen härpäke) ja muistia kai 6 Gt kun enempää ei sopivia palikoita saanut kerjättyä. Ihan kohtuullista rautaa siis joka toimisi jos isoveli toimisi...
Koneita on kaksi samanlaista, toinen pyörittää webbiserveriä ja toinen tietokantaa.
Tietokantapalvelin pääseekin helpolla, se pyörii yleensä 2-3:n loadilla, eli tehoa on siis reservissä (ja myös joidenkin rakastama iostat kertoilee saman suuntaista). Jokin aika sitten tehty kantapäivitys onneksi kevensi rakenteet siten että tämä palvelin jaksaa taas palvella hymy naamalla
Itse webbiserveri sitten saakin paiskoa työtä sen edestä, eli päiväaikaan loadit ovat noin neljän luokkaa eli teoreettisesti täysillä tehoilla paukutellaan. Iltaa kohden sitten mennään reilun 6:n loadilla, ja sitten kun gc.com:n api kenkkuilee vain taivas on rajana eli tällöin normaalisti on 10:n tietämissä.
Eilen kun api taas teki sunnuntaitiltit niin palvelin meni 20:n kuormilla. Tällöin toki jo päivitysjärjestelmä on sulkenut perusprosessit käytöstä mutta silti api on paljon käytössä pakollisten prosessien myötä (mm. uusien kätköjen valvonta). Kun edelliset pyynnöt jäävät odottamaan minuuttitolkulla apin vastauksia ja uusia pyyntöjä on pakko kuitenkin yrittää niin tällöin on maanvyöryefekti jonka ylärajan palvelin (tai haksu10:n hätätoimenpiteet) määrittelee... itse asiassa tuo 20 tuntuu olevan yläraja johon palvelin suostuu. Mutta onneksi nykypalvelin pystyy tämänkin tilanteen hallitsemaan... edellinen ajautuikin tällöin monen tunnin kadoksissaoloon ja palasi sitten joskus kaikki prossessit webbiserveristä croniin päättyneitä.
Mutta kehitys kulkee eteenpäin ja koko ajan etsin keinoja millä vähentää kuormitusta ilman että se tapahtuu materiaalin ajantasaisuuden kustannuksella. Helppo tapa kun toki olisi laittaa dataa valumaan apista hitaammin mutta tavoitteena on juuri päinvastainen; koittaa repiä sieltä dataa entistä nopeammin jos muualta saa tehonkulutusta vähennettyä.
7.7.2018 jälkeen kirjoittamani viestit olen kirjoittanut yksityishenkilönä ja kätköilijänä "haksu10", en sivustoon liittyvänä taikka sen ylläpitäjänä.
Kyseistä päivämäärää edeltävät viestit voivat olla sivustoon liittyviä ylläpidollisiakin viestejä.
Kyseistä päivämäärää edeltävät viestit voivat olla sivustoon liittyviä ylläpidollisiakin viestejä.
Re: Uusien kätköjen valvontajärjestelmä
Onkos virtualisoitu, vai ihan normaalilla?
Onko ajateltu apihaun siirtoa tietokantapalvelimelle, koska sinne ne tiedot kuitenkin menee?
Periaatteessa foorumin kanta voisi olla www-palvelimella, koska se ei juurikaan kätkökantaa kaipaa.
Saattaa tietty olla, että ole ihan pihalla, kuin talomies...
Onko ajateltu apihaun siirtoa tietokantapalvelimelle, koska sinne ne tiedot kuitenkin menee?
Periaatteessa foorumin kanta voisi olla www-palvelimella, koska se ei juurikaan kätkökantaa kaipaa.
Saattaa tietty olla, että ole ihan pihalla, kuin talomies...
Re: Uusien kätköjen valvontajärjestelmä
Virtualisointi -kysymys menee jo niihin mihin itse en tiedä vastauksia... kuulemma "namevirtualhost" on avainasemassa palvelimen konffeissa joten olisikö tämä sitten virtualisoitu.Seq kirjoitti:Onkos virtualisoitu, vai ihan normaalilla?
Onko ajateltu apihaun siirtoa tietokantapalvelimelle, koska sinne ne tiedot kuitenkin menee?
Periaatteessa foorumin kanta voisi olla www-palvelimella, koska se ei juurikaan kätkökantaa kaipaa.
Saattaa tietty olla, että ole ihan pihalla, kuin talomies...
Täytyypä miettiä tuota joidenkin apien siirtoa tietokantapalvelimelle, ainakin uusien kätköjen valvonta olisi osuus mikä olisi kohtuudella siirrettävissä. Jotkut prosessit luovat samalla tiedostopohjaisia osuuksia ja ne on toisaalta selkeämpi pitää www-palvelimella, vaikkakin nekin olisi toki mahdollista rakennella tietokantapalvelimen puolelle. Mutta täytyy ajatella hommat siten ettei vaan siirrä koko kuormitusta palvelimelta toiselle
Foorumin suhteen se on mitä on, missä on ja miten on. Koko helvetinkone yli 60:n tietokantataulun kera on sellainen että "Jos se toimii, pidä näpit erossa"
Mutta jotain mietteitä taas alkoi heräämään miten saada www-palvelimen kuormitushuippuja laskemaan; esimerkiksi tuo uusien kätköjen valvonta voisi jo kuormitusta muuttaa apin hitaustilanteissa.
7.7.2018 jälkeen kirjoittamani viestit olen kirjoittanut yksityishenkilönä ja kätköilijänä "haksu10", en sivustoon liittyvänä taikka sen ylläpitäjänä.
Kyseistä päivämäärää edeltävät viestit voivat olla sivustoon liittyviä ylläpidollisiakin viestejä.
Kyseistä päivämäärää edeltävät viestit voivat olla sivustoon liittyviä ylläpidollisiakin viestejä.
Re: Uusien kätköjen valvontajärjestelmä
Namevirtualhost on apachen tapa tehdä eri domainien ja hostien ohjausta, eli ei.haksu10 kirjoitti:Virtualisointi -kysymys menee jo niihin mihin itse en tiedä vastauksia... kuulemma "namevirtualhost" on avainasemassa palvelimen konffeissa joten olisikö tämä sitten virtualisoitu.Seq kirjoitti:Onkos virtualisoitu, vai ihan normaalilla?
Onko ajateltu apihaun siirtoa tietokantapalvelimelle, koska sinne ne tiedot kuitenkin menee?
Periaatteessa foorumin kanta voisi olla www-palvelimella, koska se ei juurikaan kätkökantaa kaipaa.
Saattaa tietty olla, että ole ihan pihalla, kuin talomies...
Täytyypä miettiä tuota joidenkin apien siirtoa tietokantapalvelimelle, ainakin uusien kätköjen valvonta olisi osuus mikä olisi kohtuudella siirrettävissä. Jotkut prosessit luovat samalla tiedostopohjaisia osuuksia ja ne on toisaalta selkeämpi pitää www-palvelimella, vaikkakin nekin olisi toki mahdollista rakennella tietokantapalvelimen puolelle. Mutta täytyy ajatella hommat siten ettei vaan siirrä koko kuormitusta palvelimelta toiselle
Foorumin suhteen se on mitä on, missä on ja miten on. Koko helvetinkone yli 60:n tietokantataulun kera on sellainen että "Jos se toimii, pidä näpit erossa"
Mutta jotain mietteitä taas alkoi heräämään miten saada www-palvelimen kuormitushuippuja laskemaan; esimerkiksi tuo uusien kätköjen valvonta voisi jo kuormitusta muuttaa apin hitaustilanteissa.
Ajattelin jotan xen:iä tai vmware:a.