DISCOURSE: Live-seurannan päivitysviive ruuhkahuipuissa

Tämä ongelma havaittiin ja tutkittiin Tampere Cupissa, mutta mitään yksittäistä vikaa tai korjausta ei löytynyt. Syy ei ole tällä hetkellä tiedossa, sillä palvelimen kuormitus ei ole lähelläkään 100%.

Tietokannan koko on toki vuosien saatossa kasvanut kymmeniin gigatavuihin, mutta ei sekään tätä täysin selitä, koska ei muutos viime kauden viimeisestä pelistä ole niin iso.

Onko Discoursen edellinen päivitys vaikuttanut jotain, sitäkin voimme vain arvailla. Omassa laitteessanne vika ei ole, joten selaimen refreshin hakkaaminen on turhaa tai jopa haitallista.

Mietitään. Sillä välin ei voi kuin sietää.

@henkilökunta

2 tykkäystä

En tiedä johtuuko varsinainen ongelma tästä, mutta 429 vastauksia tuli useampi kun hetken aikaa oli etusivu auki:

tappara.co yhdellä selaimella/tabilla auki.

3 tykkäystä

Mielenkiintoinen havainto. Tästä on Metassa keskustelu auki - pitää tutkia lisää.

(Huom, iceman ei ole meidän iceman)

4 tykkäystä

Semmoinen huomio tästä vielä, että välittyyhän Discourseen varmasti käyttäjän oikea IP Cloudflaren/webbiserverin läpi?

Näin perstuntumalta Discoursen globaalit rajat saattaisi osua aika lähelle kun on enemmän liikennettä ilmoilla ja jos Discourse näkee kaikkien IP:t samana:

DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE : number of requests per IP per minute (default is 200)

DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS : number of requests per IP per 10 seconds (default is 50)

1 tykkäys

Pitäisi välittyä, mutta tuo on joskus ennenkin prakannut jos CloudFlaren palvelinten IP:t ovat vaihtuneet.

Mietin samaa eilen ja että pitää kokeilla ilman CloudFlarea joku peli. Olen tosin nyt mökillä vain kännykän varassa, joten en ole varma onko oikea hetki kokeilla.

No jos haluat pysyä siellä mökillä niin ei. :slightly_smiling_face:

1 tykkäys

Nyt vaan tommonen KHL-pomoliike, reteesti suoraan mökiltä noita rate-asetuksia isommalle ilmekkään värähtämättä. Potkuja voi jaella sitten myöhemmin :grin:

2 tykkäystä

CloudFlaren käyttöliittymä oli varsin käytettävä kännykälläkin, joten otin cachet tylysti pois päältä.

Koska @Spartak:lla on kovaa osaamista, niin pystytkö monitoroimaan tilannetta illan pelissä?

Ping @henkilökunta

1 tykkäys

Jätän konsolin pelin ajaksi auki, niin siitä se selvinnee.

Edit. Kokonaisuudessaan ottelun aikana tuli yhteensä viisi 429 limittiiä omalle kohdalle:

Sat, 03 Oct 2020 14:20:48 GMT
Sat, 03 Oct 2020 14:22:21 GMT
Sat, 03 Oct 2020 15:17:14 GMT
Sat, 03 Oct 2020 15:30:17 GMT
Sat, 03 Oct 2020 16:20:12 GMT

Jos mahdollista niin webbipalvelimen lokia syytä ainakin katsella, varsinkin mitä IP:itä siellä näkyy noihin 429 vastauksien aikaan.

Edit2. Tässä vielä debuggausta helpottamaan viimeisimmän 429-vastauksen headerit kokonaisuudessaan:

HTTP/2 429 No Reason Phrase
server: nginx
date: Sat, 03 Oct 2020 16:20:12 GMT
retry-after: 57
x-runtime: 0.001114
X-Firefox-Spdy: h2

Pyyntö oli POST:

/message-bus/7c8b2667fb15408cXXX/poll (16 merkkiä korvattu lopusta XXX:llä)

2 tykkäystä

Ping @ljpp Onko vielä löytynyt tähän mitään selvyyttä? Onko hajua olikohan 429-vastauksia palautunut muillekin hidastelusta kärsineille?

Ei ole löytynyt viisasten kiveä tähän vielä. Globaalien rate limit asetusten ei pitäisi olla juurisyy, koska rajoittimeen osuminen tuottaa loppukäyttäjälle virheilmoituksen. Nythän sellaisia ei tule, vaan näkymän päivittyminen ottaa 30 sekunnin tuumaustauon.

Katselin hieman Discoursea ja näyttäisi että noita message-busin pollauksesta johtuvia 429-vastauksia tulee varsinkin jos Nginxissä ei ole rate limittejä (IP-tulvan alla, pyynnöt näkyvät Discourselle identtisenä IP:nä). Tulvankin alla Discourse vastaa puhtaaseen uuteen sivupyyntöön OK, ja viestejäkin voi lähettää, mutta pollaus (mikä näyttää uudet viestit jne) lyö luukut kiinni. Näkyy käyttäjälle, jolla esim. otteluseuranta auki, kuin olisi vain hiljaista.

Eihän Discoursen konfiguraatiossa ole kommentoitu pois “templates/web.ratelimited.template.yml”, tai sinne lisätty niin suuret rajat että se ei vaikuta? Tämä näyttäisi lisäävän Nginxiin rate limit parametrit, ja jos tähän pyyntö tyssää ennen kuin Discourse käsittelee pyyntöä, niin tulee “tyly” Nginxin virhevastaus (ei lokalisoitu kuten näissä nähdyissä 429-vastauksissa). Tosin Discourse osaa näitäkin vastauksia näyttää kauniimpina virheviesteinä, mutta sivun puhdas uusi lataus näissä tapauksissa näyttää tämän tylyn Nginxin 429-sivun. Ja mikään muukaan interaktio sivuston kanssa ei pelaa.

Tältä pohjalta löisin vieläkin vetoa sen puolesta että kyseessä on juuri tämä Discoursen sisäisestä RateLimiteristä johtuvat 429-vastaukset, ja tämä näyttäisi melko varmasti johtuvan siitä että Discourselle näkyvät IP:t eivät ole uniikkeja.

4 tykkäystä

Ei ole pois kommentoitu. Myöskään *.ratelimited templatea tai nginx-konfiguraatiota ei ole muokattu. Ylipäätään ympäristömme perustuu niin paljon default konfiguraatioon kuin mahdollista. Vain pari pluginia on käytössä ja @ozzi on tehnyt kevyet muokkaukset etusivun layouttiin.

params:
  reqs_per_second: 12
  burst_per_second: 12
  reqs_per_minute: 200
  burst_per_minute: 100
  conn_per_ip: 20

Koska tätä ongelmaa ei havaittu keväällä, mutta tällä kaudella se todettiin heti Tampere Cupissa (aktiviteetti ei huippulukemissa), niin tekisi mieli epäillä Discourse 2.5 päivityksen regressoineen jotain (Päivitimme 11.8). Hankalampi kysymys on, että mitä.

3 tykkäystä

■■■■■■■■■■■ ongelma kerrassaan ja alkaa jo vähän ärsyttämään.

Tutkailin, että tietokanta on varsin iso ja erityisesti post_timings taulu hulppeat 20 GB. Tästähän seuraa se, että tietokanta reilusti isompi kuin serverin RAM muisti (16GB), joten operaatioita tehtään väistämättä paljon SSD levyllä. Kehittelin siis teoriaa, että tietokanta ei pysy käyttöliittymän tahdissa.

Mutta kun katselee UpCloudin metriikkaa, niin Disk I/O on syyskaudella ollut alle kevään tason, joten siitäkään ei ainakaan alustavassa tutkimuksessa ole selitykseksi.

Koska CPU kuormakaan ei antanut vastausta kysmykseen, niin pitänee kuitenkin tuijotella levyliikenteen mittareita seuraavan pelin ajan ja katsoa mitä tapahtuu.

2 tykkäystä

Pistä samalla vielä työpöytäselaimella otteluseuranta auki ja ota kehittäjäkonsolista “Network” -välilehti auki. Siihen pamahtaa illan mittaan tuhansia rivejä, mutta filtteriin jos laittaa “status-code:429” niin näkyviin tulee, jos on tullakseen, pelkästään oleelliset. Saisi ainakin lisäselvyyttä etten minä ole ainoa joka noihin 429-vastauksiin törmää (sillä tästä 429:stä jauhan kun se sopii kuin nenä päähän oireiden kanssa).

Taulu on tosiaan suuri, mutta varsinkin SSD:n päällä vaikka kanta joutuisi levyoperaatioita tekemään, niin ei tuo mahdottomalta tehtävältä vaikuta. Mutta tässä on sen verran monta muuttujaa mukana että ei voi kuin mutuilla. Ehkä yksi vaihtoehto voisi olla ajaa manuaalisesti esim. noita SQL-komentoja mitä Discourse tekee post_timings -taulua vasten, näkisi karkeasti viipyykö vastaus tuntuvasti.

Discoursessa on muuten myös näppärä mini profiler (Alt+p), silläkin voinee saada jotain osviittaa mihin palvelimen puhinaan aikaa kuluu. Tosin se ei taida toimia pollauksien eikä timingsien kanssa damnit.

2 tykkäystä

Kymmeniä 429:ä tuli tänään. Pääsin koneen äärelle vasta hiljattain, joten en suoralta kädeltä hidastelua nähnyt, mutta HTTP/2 429 “Olet suorittanut toiminnon liian monta kertaa. Odota 2 minuuttia ennen kuin yrität uudelleen.” sitä melkoisen varmasti aiheuttaa.

Katso nyt vielä kerran varmuuden vuoksi Nxingin lokista misä on aikaleiman Fri, 09 Oct 2020 18:00:17 GMT liepeillä.

Joo, ei auttanut web.ratelimited -arvojen kaksinkertaistaminen. Tutkinta jatkuu. Sain tiimiltä vastauksenkin, mutta se ei kyllä kuulosta oikealta.

1 tykkäys

Tilanne kehittyy. Olen yrittänyt pumpata kehitystiimiltä vastausta, että onko ohjelmistossa muuttunut jotain kesän aikana, joka aiheuttaa tämän jumittamisen. Eivät ole vastausta antaneet, mutta ovat kuitenkin laittaneet kehitystiimin ykköspyssyn ja perustajajäsenen tutkimaan asiaa.

Sitä odotellessa otan eilisen purkkavirityksen pois ja laitan toisen tilalle. Se ei mielestäni ole korjaus tilanteeseen, mutta koska CPU kuorma ei ole ollut lähelläkään 100%, niin yritän muuttaa asetuksia niin että prosessorista puristettaisiin lisää mehuja irti, joka toivottavasti vaikuttaisi ruuhka-ajan palvelukapasiteettiin positiivisesti.

(@henkilokunta: Nostan Unicornien määrää. Ne olivat viime talven ajan 12 ja tätä tutkiessa olen laskenut ne arvoon 11. Palautan tietokantabufferit oletusarvoihin (muistia säästyy) ja nostan unicornienien määrän arvoon 15)

Edit: Purkkaviritys v2 asennettu. Jos tämä on grande catastrophe, niin palautetaan vanhat asetukset illan pelin 1. erätauolla.

9 tykkäystä

Onko Tappara.co aktiivisin Discoursea käyttävä foorumi, jos täällä esiintynyt ongelma on jopa kehittäjille kova pala purtavaksi?

1 tykkäys

Ei ole. Discourse on nykyään iso ja isoa bisnestä. Tällaisia tosimaailman tapahtumia seuraavia live-chatteja ei monella kuitenkaan ole, eikä asia ole koskaan ollut kehitystiimin fokuksessa. Ja koska me emme ole maksava asiakas (alkaen 500€ kuussa), niin meidän marinat eivät ole työlistan kärjessä.

Epäilen kuitenkin, että jolla maksavalla on nyt sama ongelma, koska homma on ottanut ns. pitoa kehitystiimissä. Tähän asti heidän linja on ollut se että tämä on keskustelupalsta, eikä chattipalvelu.

Jälkimmäistä ei ole otettu huomioon suunnittelussa, vaikka lähes reaaliaikainen päivittyvyys on aina ollut tämän avainominaisuuksia. Tämä meidänkin serveri pystyisi puskemaan varmaan 8-10x määrän liikennettä, jos se jakaantuisi tasaisesti 24/7. Live-chatilla tämän saa kuitenkin helposti jumiin (joka vuosi kipinässä), ilman mitään vikatilanteitakin. Siinä viestiä, notifikaattia ja näkymän päivittymistä sinkoilee melkoiseen tahtiin, kun muutama sata ihmistä selaa ja päivittää yhtä ketjua koko ajan.

5 tykkäystä