Palvelimen kesäloma

[haksu10]

Moron,

kauniiden kesäpäivien myötä myös geocache.fi:n palvelimet lomailevat joten datan ajantasaisuus voi olla normaalia heikompaa ja palvelu hidastella.

Tuo oli nätisti muotoiltu; todellisuudessa geocache.fi:llä on nyt ongelma ja palvelinvastaava ilmoitti juuri pakanneensa kassinsa ja painuvansa lomalle 10 päiväksi (enkä ehtinyt kyselemään asiantuntija-apua) joten asiaan ei pikavauhdilla saa nyt täydellistä korjausta.

Ongelma liittyy levynkäyttöön; levyjen luku-/kirjoitusnopeus loppuu kesken. Nyt kiihkeän kätköilykauden alettua ongelma näyttää räjähtävän käsiin, tosin gc.comin kielto tarjota kaikkien Suomen kätköjen lataamista yhdessä paketissa on lisäksi nostanut tarvetta ladata latausvaiheessa parsittavaa GPX-dataa joka on merkittävä levydataliikenteen aiheuttaja.

Tarkempi pullonkaulan analyysi jää kuitenkin ainakin tuonne 10+ päivän päähän ja asiantuntija-apuun. Mutta olen pari päivää tehnyt systeemiin sen minkä voin, ja homma jatkuu kiivasti edelleen. Karsin mm. härveleiden ylläpitämiä tapahtumalokeja siltä osin kuin ne eivät ole välttämättömiä ja käyn härveli kerrallaan systeemiä läpi ja tutkin mistä pystyy levynkäyttöä karsimaan.

Muuttelen myös eri härveleiden toimintoja joka mahdollisesti voi aiheuttaa hetkellisiä ongelmia joissain palveluissa, ellei kaikki mene putkeen.

Tällä hetkellä on myös vähempiarvoisten (mm. attribuutit, kätköjen kuvat) lataus- ja käsittelyprosessien saamaa aikaa vähennetty kätkö- ja lokidatan saamikseksi paremmin ajan tasalle. En vielä tässä vaiheessa osaa sanoa saanko näille vähempiarvoisille prosesseille annettua normaalin määrän aikaa käyttöön ennen kuin asiantuntija saa selvitettyä tilanteen.

Tärkeimmät toiminnot kuten uusien kätköjen havaitseminen/hälytys jne. ovat ykkösprioriteetilla eli niissä ei pitäisi tapahtua edes hetkellisiäkään ongelmia.

Mutta kyllä tästäkin ongelmasta taas pääsee voiton puolelle, nyt voi vain ottaa hieman pidemmän ajan. Koittakaa siis kestää...

[Seq]

Mitäs iostat näyttää?

Onko radit kunnossa?

Entäs kantojen indeksoinnit, tarvitaanko sortteihin levyä?

[haksu10]

Mitäs iostat näyttää?

Onko radit kunnossa?

Entäs kantojen indeksoinnit, tarvitaanko sortteihin levyä?

Nämä ovat juuri niitä asioita, mihin asiantuntija tarvitaan... itse en tunne raidia tai kantaa tai edes sen optimointia/indeksointia jne; kuten en linuxiakaan eli olen vain tyhmä koodari

Mutta iostat ja top kertoilee tämännäköisiä tietoja, jos näistä joku ymmärtää / huomaa jotain outoa:

WWW-palvelin:

Koodi: Valitse kaikki

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          20.82    0.00    5.05   22.81    0.00   51.32

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda              84.76    37.90  142.21   16.77  1870.86   431.39    14.48    17.10  107.59   4.18  66.46


top - 22:17:05 up 1 day, 22:12,  2 users,  load average: 3.06, 3.67, 3.74
Tasks: 451 total,   1 running, 449 sleeping,   0 stopped,   1 zombie
Cpu(s): 15.0%us,  2.5%sy,  0.0%ni, 60.3%id, 21.5%wa,  0.2%hi,  0.6%si,  0.0%st
Mem:   6198868k total,  2704312k used,  3494556k free,   692804k buffers
Swap:        0k total,        0k used,        0k free,   572376k cached

Tietokantapalvelin:

Koodi: Valitse kaikki

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          27.47    0.00   21.54    4.52    0.00   46.47

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.66   271.54    3.38   86.48   128.08  2687.96    31.34     5.90   65.69   1.99  17.92


top - 22:17:25 up 1 day, 22:10,  2 users,  load average: 2.07, 2.57, 2.65
Tasks: 190 total,   1 running, 189 sleeping,   0 stopped,   0 zombie
Cpu(s): 24.5%us, 22.9%sy,  0.0%ni, 52.2%id,  0.2%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   6198868k total,  5682780k used,   516088k free,   305932k buffers
Swap: 23437304k total,    29964k used, 23407340k free,  3632804k cached

[Seq]

Iowait on asia jota kannattaa seurata, kun se kertoo, paljonko järjestelmä joutuu odottamaan io:ta.

Ensimmäinen iostatin ajo yleensä antaa julmia lukemia, mutta "iostat 1 5" kertoo todellisempaa lukemaa.

[Seq]

Mitäs iostat näyttää?

Onko radit kunnossa?

Entäs kantojen indeksoinnit, tarvitaanko sortteihin levyä?

Nämä ovat juuri niitä asioita, mihin asiantuntija tarvitaan... itse en tunne raidia tai kantaa tai edes sen optimointia/indeksointia jne; kuten en linuxiakaan eli olen vain tyhmä koodari

Mutta iostat ja top kertoilee tämännäköisiä tietoja, jos näistä joku ymmärtää / huomaa jotain outoa:

WWW-palvelin:

Koodi: Valitse kaikki

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          20.82    0.00    5.05   22.81    0.00   51.32

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda              84.76    37.90  142.21   16.77  1870.86   431.39    14.48    17.10  107.59   4.18  66.46


top - 22:17:05 up 1 day, 22:12,  2 users,  load average: 3.06, 3.67, 3.74
Tasks: 451 total,   1 running, 449 sleeping,   0 stopped,   1 zombie
Cpu(s): 15.0%us,  2.5%sy,  0.0%ni, 60.3%id, 21.5%wa,  0.2%hi,  0.6%si,  0.0%st
Mem:   6198868k total,  2704312k used,  3494556k free,   692804k buffers
Swap:        0k total,        0k used,        0k free,   572376k cached

Tietokantapalvelin:

Koodi: Valitse kaikki

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          27.47    0.00   21.54    4.52    0.00   46.47

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.66   271.54    3.38   86.48   128.08  2687.96    31.34     5.90   65.69   1.99  17.92


top - 22:17:25 up 1 day, 22:10,  2 users,  load average: 2.07, 2.57, 2.65
Tasks: 190 total,   1 running, 189 sleeping,   0 stopped,   0 zombie
Cpu(s): 24.5%us, 22.9%sy,  0.0%ni, 52.2%id,  0.2%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   6198868k total,  5682780k used,   516088k free,   305932k buffers
Swap: 23437304k total,    29964k used, 23407340k free,  3632804k cached

Www-palvelimella oli yksi zombi. Jos se luuraa siellä pitkään, niin se saattaa olla merkki ongelmista.

Www-palvelimella ei myöskään ollut swappia, muistia kylläkin oli, eli ehkä harkittua?

Kun ajaa top:ia, voi painaa ykköstä, niin se näyttää kuorman per prosessori...

hdparm:lla voisi tietysti testata lukunopeutta levyillä, mutta se/siihen vaikuttaa muu kuorma.

[haksu10]

Iowait on asia jota kannattaa seurata, kun se kertoo, paljonko järjestelmä joutuu odottamaan io:ta.

Ensimmäinen iostatin ajo yleensä antaa julmia lukemia, mutta "iostat 1 5" kertoo todellisempaa lukemaa.

Www-palvelimella oli yksi zombi. Jos se luuraa siellä pitkään, niin se saattaa olla merkki ongelmista.

Www-palvelimella ei myöskään ollut swappia, muistia kylläkin oli, eli ehkä harkittua?

Kun ajaa top:ia, voi painaa ykköstä, niin se näyttää kuorman per prosessori...

hdparm:lla voisi tietysti testata lukunopeutta levyillä, mutta se/siihen vaikuttaa muu kuorma.

Nooh, tämä menee niin nörtiksi että asiantuntijaa juuri siitä syystä tarvitsen; hän tietää myös kaikki swapit sun muut ja tarkoitukset ja palvelimen konffaukset yms. Itse en siis osaa mitään linuxista (enkä mysql:sta), korkeintaan pystyn kirjoittamaan jonkun ihme rimpsun minkä joku viisas on joskus kertonut, joka kertoo jotain mistä en tajua, mutta joka kuulemma kertoo sen hyvin.

Ainoa, mihin kiinnitin huomiota oli wait-arvot, tässä esimerkiksi top:n kertomat neljän prosessorin (nyt kun tiedän miten sen näkee) tiedot normaaliruuhkaiselta ajalta:
Cpu0 : 35.8%us, 3.9%sy, 0.0%ni, 40.6%id, 18.7%wa, 0.3%hi, 0.6%si, 0.0%st
Cpu1 : 36.1%us, 5.5%sy, 0.0%ni, 1.6%id, 54.8%wa, 0.0%hi, 1.9%si, 0.0%st
Cpu2 : 43.0%us, 5.2%sy, 0.0%ni, 1.3%id, 50.5%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 58.8%us, 1.3%sy, 0.0%ni, 28.4%id, 11.4%wa, 0.0%hi, 0.0%si, 0.0%st

Näissä näkyy tuo %wa joka on kohtuullisen suuri, ja viime yönä ongelmaa debugatessani totesin että koittaessani ajaa datankäsittelyä usemmalla käsittelijällä rinnakkain ei käsittely nopeutunut vaan tuo %wa pomppi keskimäärin yli 50% tasolla. Tästä ja googletuksesta sekä loogisesta päättelystä ja testailusta pääsin siihen tulokseen että kyllä levynkäyttö on nyt pullonkaula, kun vaan tietää missä.

Mutta kaiken kaikkiaan täytyy odottaa asiantuntijan paluuta, hän pystyy edes analysoimaan pitääkö minun muuttaa www-palvelimen levynkäyttöä (www-palvelimen levynkäsittely jäätyy) vai tietokantaa (tietokantapalvelimen levynkäsittely jäätyy) vai molempia. En nimittäin itse pysty analysoimaan missä tuo pahin pullonkaula on.

[Seq]

Mites se "iostat 1 5" ?

Tipahtiko waitti?

[haksu10]

Mites se "iostat 1 5" ?

Tipahtiko waitti?

Tuota olen testaillut ja vieläpä peräti iostat 1 20

Välillä satunnaisesti käväisee nollassa mutta myös tuolla > 70% pamahtelee. Tässäpä yksi sarja melko keskitasoisin tuloksin tuolla 20 sarjalla...

Koodi: Valitse kaikki

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          20.94    0.00    5.04   22.42    0.00   51.60
          26.57    0.00    7.73   36.23    0.00   29.47
           3.99    0.00    2.24   47.88    0.00   45.89
           6.95    0.00    3.72   51.61    0.00   37.72
           9.20    0.00    3.48   49.50    0.00   37.81
          10.17    0.00    3.63   52.06    0.00   34.14
           8.33    0.00    4.30   37.90    0.00   49.46
           4.12    0.00    1.60   24.71    0.00   69.57
           4.75    0.00    3.50   24.25    0.00   67.50
          14.71    0.00    7.23   35.16    0.00   42.89
           3.85    0.00    0.72   45.91    0.00   49.52
          10.95    0.00    3.48    9.20    0.00   76.37
          43.10    0.00    7.64    0.49    0.00   48.77
          74.11    0.00   10.66    0.00    0.00   15.23
          12.50    0.00    8.09   22.79    0.00   56.62
           2.53    0.00    1.52   24.05    0.00   71.90
           5.72    0.00    2.99   23.38    0.00   67.91
           2.00    0.00    1.50   26.68    0.00   69.83
           0.25    0.00    0.50   24.50    0.00   74.75
           5.05    0.00    2.27   25.25    0.00   67.42

[haksu10]

Palvelimien kesäloma jatkui

Sivuston toiminnan nopeuttamiseksi datankeruu- ja käsittelyosuuksiin tuli laajoja muutoksia. Mahdollisen roskadatan nollaamiseksi tein rutiininomaisen palvelinten uudelleenkäynnistyksen klo 00:17 aikoihin. Tällöin kuitenkin tapahtui odottamaton: tietokantapalvelin ei palannutkaan verkkoon.

Vaikka oli perjantaiyö niin parissa tunnissa sai MMD.net:ltä päivystäjän paikalle. Tietokantapalvelimen näyttö oli pimeänä mutta näppäimistö reagoi. Uudelleenkäynnistysyritys onnistui ja palvelin palasi verkkoon. Käynnistymisen jälkeen ilmeni, että hieman oireillut NFS -palvelu lienee lopullisesti kajahtanut ja ilmeisesti tästä syystä palvelin ei ole käynnistynyt.

Tilanne tällä hetkellä on se, ettei www-palvelin näe tietokantapalvelimen levyä. Tämän ei pitäisi merkittäviä ongelmia aiheuttaa, mutta mahdollista on että jossain www-palvelimen osuudessa koitetaan ko. levyä käyttää joten ongelmat ovat kuitenkin mahdollisia.

Palvelun (kohtuullisen) toimivuuden turvaamiseksi ei kuitenkaan vikaa aleta korjaamaan hätäisesti vaan ilmeisesti viikonlopun yli mennään tällä tilanteella ja varsinainen vian korjaus tapahtuu alkavalla viikolla päiväsaikaan, jolloin tarvittaessa palvelimille saadaan välittömästi huoltotoimenpiteitä / uudelleenkäynnistys.

Tämänhetkisessä tilanteessa on pieni riski myös sen suhteen että www-palvelimen kuormitus nousee hetkellisesti liian korkeaksi. Mikäli näin käy sivusto sulkeutuu hetkiseksi mutta muutaman minuutin päästä pitäisi tilanteen palautua normaaliksi.

Pahoittelen suuresti kaikkia mahdollisia ongelmia, mitä viikonlopun aikana tulee vastaan!

Tämän yön osalta täytyy pian siirtyä lepovaiheeseen mutta jälleen huomenna olen koko päivän selvittämässä mahdollisia ongelmia (paitsi mahdollisten ukkoskuurojen aikaan jolloin laajasta ilmajohtojen verkostosta johtuen sähköt katoavat ja pistokkeet täytyy kotikoneelta repiä irti laitevaurioiden välttämiseksi).

[haksu10]

Palvelinten kesäloma on toivottavasti nyt päättymässä

Kiitos Suuren Ja Mahtavan linux-gurun on nyt taas palvelinten välillä yhteys; itse asiassa nopeampi eli NFS-sydeemin sijaan painetaankin gigaista verkkoa pitkin dataa palvelinten välillä. Samalla www-palvelimen puolella tapahtui muutakin pientä konffailua joka voi hieman pienentää kuormitusta.

Nyt on edessä taas palaaminen normaaliin eli molempien palvelinten pistäminen työn touhuun. Sen myötä saa datan jälleen ajantasaisemmaksi, varsinkin kun hitaan api-lataamisen saa hajautettua kahdelle palvelimelle.

Toivotaan etten lähipäivien aikana saa paljoa rikki, mutta kuitenkin, nyt ollaan taas menossa parempaan päin joten koittakaa kestää mahdolliset sekasotkut...

[haksu10]

Palvelinten kesäloma on toivottavasti nyt päättymässä

Lukuisten yhteydenottojen johdosta piristän tätä ketjua tilannetiedoituksella (joten voin jatkossa murista "mä olen keskustelussa kertonut..."

Palvelinten ylikuormitusongelmien pitäisi nyt olla ohi.

Tähän vaadittiin lähes kaikkien taustaprosessien uudelleenrakennus koska sivuston hitauden ja kuormitusongelmien takana oli se, että palvelimien (varsinkin www-palvelimen) levyt eivät kesän myötä enää pystynyt palvelemaan sekä käyttäjien sivu- ja datalatauksia että datan latausta ja käsittelyä gc.comin apidataliitynnästä. Myöskään tietokantapalvelimelle ei enempää taustatyötä pystynyt ohjaamaan koska seuraavaksi levynkäyttöongelma olisi siirtynyt sinne.

Ennen erilliset latausprosessit latasivat dataa ja tallensivat sen levynkulmalle, josta sitten käsittelyprosessit hakivat dataa, kävivät sen läpi ja tuuppasivat kantaan & kätködatan osalta tallensivat GPX 1.1 -lähteisen datan GPX 1.0 -formaatissa levylle. Vaikkakin hallittavuudeltaan tämä tekniikka oli selkeä niin nyt se kaatui levyn maksimikäyttömäärän kahleisiin. Nyt lataus- ja käsittelyprosessit ovat yhdistetty joten data ladataan muistiin ja käsitellään lennossa.

Taustaprosessit ovat pääpiirteittäin viimein kunnossa ja paluun myös datan ajantasaisuuden osalta normaaliin on käynnissä. Toistaiseksi kuitenkin kätködata saattaa olla jopa reilun vuorokauden jäljessä, lokit jopa yli kaksi vuorokautta. Dataa kuitenkin virtaa palveluun koko ajan joten kyllä ne puuttuvat lokit varmasti sieltä tulevat.

Syy miksen tee radikaaleja toimenpiteitä datan saamiseksi ajan tasalle on se, että kasvatan lataus&käsittelyprosessien käyttöönsaamaa tehoa vähitellen jotta pystyn seuraamaan, miten palvelimet käyttäytyvät ja missä vaiheessa mahdollisesti alkaa tulemaan ongelmia. En halua ajaa taas palvelimia polvilleen ja sitten hätävähentäen sekä hätälisäten tehoa koittaa löytää kultaista keskitietä missä data on riittävän tuoretta mutta palvelimet kestävät. Hallittu kuormituksen kasvattaminen vain on hitaampaa jotta tilanteen näkee eri kuormitustilanteissa (iltaisin aktiivisimman sivujen käytön aikaan, aamuyöstä raskaimpien dataprosessointien aikaan jne).

Mutta tässä asiassa vanha sananlasku "hitaasti hyvä tulee" pitää paikkaansa, ja uskoisin (ja myös sivulatausten keskiarvoajat kertovat) että sivujen latautuminen on jo silminnähden pirteämpää. Toki jotkut tietyt tehollisesti raskaat sivut edelleen voivat hidastella, mutta tämän melko raskaan projektin jälkeen pääsee paneutumaan niihin. Ehkäpä pääsee taas jotain uuttakin väsäämään ja hoitamaan viikkojakin odottaneita yhteydenottoja... pahoittelut vastausta odottaville!

Koittakaa siis kestää kun haksu-setä taas säätelee...

[haksu10]

Jälleen tilannetietoa:

Uusien kätköjen suhteen oli ongelmia eilisillan ja tämän päivän osalta. Uusien valvontaprosessit eivät saaneetkaan läpi kätkötietojen täydennystä joten homma tyssäsi kesken. Tämä näkyi valitettavasti myös kännyhälyissä, niitä ei lähetetty em. ajalta josta suuren suuret pahoitteluni!

Lataus-/käsittelyprosessien saamaa tehoa on taas kasvatettu. Nyt kaikki data (kätköt, lokit, kuvat, attribuutit) on nyt jo alle vuorokauden ikäistä ja ajantasaisuus kasvaa koko ajan. Koska laskennallinen ajantasaisuusarvio ei koskaan vastaa todellisuutta katson huomenna, mille tasolle ajantasaisuus on muodostunut ja säädän taas tarvittaessa lisää tehoa prosesseille.

Palvelinten kuormitustilanne on (em. tehotarvelisäyksestä huolimatta) edelleen hyvä eikä ylikuormituspiikkejä ole esiintynyt. Aika näyttää miten paljon tehoa vielä tarvitaan ja alkaako se vaikuttamaan kuormitukseen. Nyt kuitenkin on tiedossa tapahtumaketju mikä ajaa palvelimet ylikuormille, eli levyn luku-/kirjoituskapasiteetin ylittyminen, joten on helpompaa pitää tilanne kurissa.

Tässäpä tältä erää lyhyt tilannetiedote. Tilanne näyttää siis viimein taas hyvin positiiviselta ja toivotaan etten enää saa mitään suuria katastrofeja aikaan taustaprosessien säätely- ja paranteluhommissa

[stebu]

Aiheuttaisiko vähemmän päivityskomentoja, jos esim "Löytömäärän kehitys ja löytömäärät kuukausittain" kokonaislöytömäärä olisi sama kuin kuukausien summa? Minulla ainakin heittää 10 kätkön verran. Ainoastaan "Maasto- ja vaikeustaulukko" näyttää oikean kokonaislukeman.

It's not all about the numbers, mutta kuitenkin

[haksu10]

Aiheuttaisiko vähemmän päivityskomentoja, jos esim "Löytömäärän kehitys ja löytömäärät kuukausittain" kokonaislöytömäärä olisi sama kuin kuukausien summa? Minulla ainakin heittää 10 kätkön verran. Ainoastaan "Maasto- ja vaikeustaulukko" näyttää oikean kokonaislukeman.

It's not all about the numbers, mutta kuitenkin

Eipä vaikuta päivityskomentojen määrään; samat tiedot on kuitenkin haalittava.

Tähän hätään en ehdi yksitellen käymään löytöjäsi läpi, joten latelen normaalit litaniat. Allaolevista ainakaan tuplalöydöt eivät päde sinuun (tällöin Maasto- ja vaikeustaulukon kokonaismäärä olisi liian pieni) enkä suoraan löytänyt toki muistakaan viimeominaisuuksista selitystä. Mutta ehkä joku muu ainakin saa avun tilasto-ongelmiin ja tutkin asian osaltasi heti kun ehdin.

* Tilastot eivät ole reaaliaikaisia, loggaukset saapuvat palveluun yleensä alle vuorokauden viiveellä

* Tilastokuvat eivät kuormitussyistä päivity jatkuvasti vaan ne ovat välimuistitettu ja tehdään uudelleen kun ne ovat vanhoja

* Tilastokuvissa käytetään eri kokonaismäärätietoa; jotkut kuvat käyttävät virallista geocaching.com:n lukemaa ja toiset geocache.fi:n lokimäärästä saatua lukemaa riippuen siitä, miten muuten tarvitsee dataa kuvaa varten kerätä

* Mahdolliset saman kätkön tuplalöytöloggaukset sekoittavat numeroita, mahdolliset tuplaloggaukset voi tarkastaa täältä => Tilastot: Lisätilastot

* Ulkomaan löydöt eivät päivity geocache.fi:hin automaattisesti eikä myöskään ulkomaan kätköjen tiedot. Premium voi tiedot päivittää Voit syöttää tällä lomakkeella My Finds -pocket querysi tilastojen tarkentamiseksi. -toiminnolla nämä löydöt (sekä tarkentaa suomilöytöjen järjestystä) => Tilastot: Ylläpito

[stebu]

Eipä vaikuta päivityskomentojen määrään; samat tiedot on kuitenkin haalittava.

Siis siihen, että kärsimättömät kätköilijät pyytävät tilastojen päivitystä, kuulemma kuormittaa!

tutkin asian osaltasi heti kun ehdin.

Kiitos vaan mutta ei tartte, kyllä ne sieltä putkahtaa.