Dedillä liikenne-ennätys

[weatherc]

Dodiin, toukukuussa laitetaan sitten dedin liikenne-ennätys aivan uudelle tasolle kun kuukauden liikenne ylittää ensimmäisen kerran 0.5 TB, ollen suunnilleen 580 GB, eli ensimmäisen kerran ollaan käytetty yli 10% kuukausi-kiintiöstämme
Edelliseen ennätykseen, joka oli viime kuulta, on eroa peräti yli 30%.
Siihen sisältyy GFS:ät sekä viikottaiset 15 GB uppaukset backupservulle.

Se tekee keksimääräiseksi nopeudeksi noin 1.8 Mbit/s, joka on muuten yli Hetznerin kaikkien tuhansien purkkien keskiarvon, luin jossain että heidän keskiarvo on suunnilleen 1.2 Mbit/s per purkki. 

Koko dedin noin 9.5 kk aikana ei olla saatu kulutettua edes yhden kuukuaden verran trafiikkia vaan kokonaismäärä on tällä hetkellä 3.3 TB 

[Snowi]

Luvut sen kuin kovenee  . Sinänsä tätä voi pitää aikamoisena yllätyksenä, sillä FMI:n Pauli Jokinen sanoi toukokuun maasalamamääräksi vain 1500, kun keskiarvo on 7000, eli toukokuu oli salamoiden osalta moninkertaisesti normaalia hiljaisempi. Ero varsin viime vuoteen on huima, mutta kesäkuu ei voi olla viime vuotta huonompi 

Kyllä tässä meidän purkissa näyttäisi näköjään varaa olevan, jos ei olla lähes 10kk aikana saatu kulutettua edes yhden kuukauden trafiikkia  . Mielenkiinnolla odotan mitä kesäkuu tuo tullessaan, ainakin kesäkuu alkaa heti ihan mukavalla ryminällä 

[weatherc]

Kyllä tässä meidän purkissa näyttäisi näköjään varaa olevan, jos ei olla lähes 10kk aikana saatu kulutettua edes yhden kuukauden trafiikkia

Hetznerillä on aikas mukavat "liikennerajat" kyllä, 5TB/kk, ei lopu ihan heti näin peruskulutuksella, ja lisää voi ostaa jos se ei riitä,

[weatherc]

Kesäkuu aloitettiin sitten vauhdilla, tehtiin uusi päiväkohtainen ennätys liikenteessä, karvan verran alle 50 GB tai 4.72 Mbit/s jaettuna koko tastaisesti koko vuorokaudelle
Lukemia jota näin "vauhtimittarissa" oli siinä 25 Mbit/s parhaimmillaan, ja se ei edes pävity jatkuvasti vaan 20 sek välein joten piikki on varmaan voinut olla suurempikin...
Liitteenä viime 7 päivän käppyrä Nginxin connextionseista joka kuvaa aika hyvin missä ollaan menty

On myös ollut tarkkailussa loadit viime päivinä kun enemmän liikennettä ja jotain siellä nyt panttaa pikkasen koska ovat kyllä olleet liian korkeat. Ongelman löytäminen on vain aika vaikea koska yksittäiset Apachen kutsut/luvut ei näy oikeen missään muuta kun Apachen omalla server-status-sivulla mutta...

- joku Apachen kautta tuleva kutsu se on, cronjobilla ajettavat ajastetut php:t kun ei mene sen kautta ja ne näkyvät erikseen prosessilistassa
- pari epäilystäkin on..
   - NSJson.php, eli skripti joka parsii NSGraph.txt-filun NSD:n käyrille. Tätä ei voi tehdä jacascriptillä (tai voi mutta js ei jaksa). Ongelma siinä on ajax-päivitys, se tuuppaa jokaikiselle kutsulle uniikin numrosarjan ja siten Nginxin cache:lla ei ole mitään hyötyä siihen
   - Piwik ja muut omat laskurit jotka käyttävät MySQL:ää, tämä on pääepäilty. Mysli ja kova liikenne ei tunnetusti ole hyvä yhdistelmä varsinkin jos mysliä käyttää reaaliajassa kuten nuo laskurit tekevät. Ongelma siinähän on vaan se että se on ainut tapa jolla saadaan "omatekoiset" users onlinet ja ennenkaikkea max users onlinet. Mutta jollei muu auta niin ne täytyy dumpata.

[Snowi]

Myös omalla sivustolla tuli uusi päiväkohtainen kävijäennätys, mutta max onlinessa ei päästy lähellekään sitä kuuluisaa elokuun 8. päivää 
Aika kovat lukemat näköjään pistettiin tänään tauluun, mutta olihan tämä päivä harvinaisen pitkäkestoinen salamoinnin osalta, joten kävijämäärät pysyivät tasaisesti suurina. Sitten kun tulee päivä, jossa ukkosrintama tulee etelästä yli Itämeren ja matkaan siitä läpi Suomen, niin silloin luulisi uuden ennätyksen taas tulevan niin että heilahtaa 

Mikäköhän tossa Apachen loadissa oikein on. Toivottavasti ongelma ei ainakaan tässä laajuudessa johdu noista omista kävijälaskureista, sillä ne ovat aivan loistavia. Varsinkin max online.
Onko toi ongelma pahakin, hidastaako se esim. sivustoja? Tänään kyllä näytti toimivan ainakin oma sivusto aivan loistavasti, enkä mitään hidastuneisuutta havainnut ollenkaan. Ero viime vuoden webhotelliin on huima, sillä silloin sivusto saattoi alkaa toimimaan hitaanlaisesti tai välillä yhteys menetettiin kokonaan.

[weatherc]

En huomannut minäkään hidastumista vaan sivut latautui kyllä ihan ok. Tässä varmaan auttaa sekin että sivu on voinut tulla Nginxin cachesta jolloin Apachea ei häiritä laisinkaan sen filun osalta.

Syy miksi olen noita nyt seurannut on että nyt ollut hyvä tilaisuus saada mutu että missä mennään kun "jonkin verran enemmän liikennettä" kun sesongin ulkopuolella muttei kuitenkaan sen kuuluisan elokuun 8. tapaista ruuhkaa.
Koitin tuossa yhdessä vaiheessa laskea sivuilta että missä suunilleen mentiin users onlinessä yhteensä js silloin oltiin jossain reilussa 500:ssa, viime vuonnahan mulla ja jamolla oli yhteensä yli 2000 parhaimmillaan....

Se missä olen asiaa huomannut, sen lisäksi että itse load-lukema ollut tänäänäkin koko päivän yli 1 ja suuren osaa päivää yli 2, on että apachen httpd-prosessien CPU-usage-prosentit oli parin kolmen prosessin osalta lähes jatkuvasti yli 50% välillä käyden 100%:ssa.
Voisin jossain vaiheessa katsoa läpi nuo  meitin tutkasivut Firebugin filulataus-listalla ja katsoa että onko niissä jotain "ylimääräistä" apachekutsua tai muuta sellaista, se kun kertoo todella näppärästi että mitä kaikkea se sivu latailee

Apachen server-status-sivua kun seurailin niin NSjson.php oli se filu mikä siellä eniten näkyi koska siinä on se uniikki numerosarja joten siinä Nginxin cache ei hyödynnä pätkääkään ja jokaikinen kutsu siihen parsittiin erikseen. Paras tässä olisi jos noiden käppyrien päivitykset saisi tehtyä selaimeen päin täysin staattisesti eli Nginx hoitaisi senkin ilman Apachen häiritsemistä. Tämä olisi täysin mahdollista kyllä tehdä esim. siten että ajais muokatun NSJsonin ajastuksella taustalla kerran minuutissa joka tallentaa json-filun servulle ja tämä sitten annettais selaimelle.
Muokkaus olisi itse asiassa helppo kyllä tehdä.

Se mikä voisi ajatella että on raskas, ja varmaan olisikin ilman Nginx-cacheta eli nslmap.php niin vilahti listassa vain, aivan kuten pitääkin, abouttirallaa kerran minuutissa.

Laskurien puolustukseksi täytyy sanoa että niitähän ei ladata kun itse sivulatauksen yhteydessä, eli tutkasivun osalta kerran per n 10 min/kävijä, joten siinä mielessä niillä olisi "puhtaat paperit".

[khyron]

On myös ollut tarkkailussa loadit viime päivinä kun enemmän liikennettä ja jotain siellä nyt panttaa pikkasen koska ovat kyllä olleet liian korkeat. Ongelman löytäminen on vain aika vaikea koska yksittäiset Apachen kutsut/luvut ei näy oikeen missään muuta kun Apachen omalla server-status-sivulla mutta...

Kannattaa laittaa accesslogiin kutsuun mennyt aika, sieltä on sitten vähän ajan päästä helppo kattoa mitkä kutsut vie paljon aikaa.
http://httpd.apache.org/docs/2.0/mod/mod_log_config.html#formats

   - Piwik ja muut omat laskurit jotka käyttävät MySQL:ää, tämä on pääepäilty. Mysli ja kova liikenne ei tunnetusti ole hyvä yhdistelmä varsinkin jos mysliä käyttää reaaliajassa kuten nuo laskurit tekevät. Ongelma siinähän on vaan se että se on ainut tapa jolla saadaan "omatekoiset" users onlinet ja ennenkaikkea max users onlinet. Mutta jollei muu auta niin ne täytyy dumpata.

Kannattaa laittaa slow query log päälle niin saa kiinni hitaat kyselyt. Tai sitten general log päälle niin näkee mahdolliset toistuvat kyselyt joita tulee huonon koodauksen takia usein. Molempia saa parsittua http://hackmysql.com/mysqlsla tolla.

[weatherc]

Kannattaa laittaa slow query log päälle niin saa kiinni hitaat kyselyt.

On ollut päällä koko ajan, ongelma on siinä ettei se kirjoita mitään siihen, eikä myslin logissa ole mitään sen tapaista erroria. Googlauksella selvisi että muillakin ollut sama ongelma siinä...

Kannattaa laittaa accesslogiin kutsuun mennyt aika

Täytyy laittaa

[khyron]

Kannattaa laittaa slow query log päälle niin saa kiinni hitaat kyselyt.

On ollut päällä koko ajan, ongelma on siinä ettei se kirjoita mitään siihen, eikä myslin logissa ole mitään sen tapaista erroria. Googlauksella selvisi että muillakin ollut sama ongelma siinä...

Se defaultti oli muistaakseni kymmenen sekuntia tai jotain muuta yhtä älytöntä, vanhemmissa versioissa ton sai laitettua vaan sekunnin tarkkuudella, enny muista ulkoo missä versiossa tuli mahdollisuus tarkempaan. Se general log on tietty toinen mahdollisuus, sen kanssa saa vaan olla tarkkana ettei täytä levyä.

[weatherc]

Mulla tuo tuning-primer käytössä ja sen mukaan:

The slow query log is enabled.
Current long_query_time = 1.000000 sec.
You have 119 out of 7690583 that take longer than 1.000000 sec. to complete

Joten eipä siellä kovin montaa hidasta kyselyä ole 19 tunnin ajalta