Kahlaamatta nyt koko ketjua läpi (en nähnyt alussa ainakaan puhuttavan), kuinka paljon noissa huipuissa on muistia vapaana? Ettei Redis swappaa ja aiheuta hitautta sitä kautta?
Mikä koko pannun load average on? Montako ydintä on yleensäkkin käytössä, onko tämä ihan topilla tämä 100%? Sehän ei sinällään vielä kerro sitä aiheuttaako tuo hitautta. Millaiset IO:t (waitit) on noilla ruuhkahuipuilla?
Esim jos Redis alkaa swapata ja kirjoittaa levylle muistin loppuessa → waitit kasvaa → Redis näyttää syövän enemmän tehoja ja tuo swappays muodostuu pullonkaulaksi.
Muisti ei ole ongelma. Sitä on aina ollut riittävästi ja juuri nyt reilusti ylikin. Discoursen muistin kulutus on ennakoitavaa – se ei nouse kuormissa.
i/o waitit eivät nähdäkseni ole nousseet merkittävästi, mutta vaatisi kunnon logittamista että pystyisi ylipäätään paremmin havainnoimaan
Nyt ongelma tulee joksikin aikaa ratkeamaan sillä, että muutamme Discoursen omaan datacenteriin ja heidän ylläpitämälle alustalle.
Se mikä jatkon kannalta kiinnostaa, on kuinka tämä voitaisiin skaalata horisontaalisesti ja mieluummin VPS-purkkeja käyttäen, koska sekin on haastava polku, että parin-kolmen vuoden välein lätkitään isompaa dedikoitua palvelinta pystyyn. Dedit muutenkin vähän vikaherkempi ratkaisu, kuin VPS.
Scaleway voisi olla tuossa ihan järkevä ratkaisu. Hajauttaa toimintoja eri instansseille. Yhdelle perus webasto, yksi Redisille, yksi kannalle jne. Niitähän saa aika helposti myös skaalattua sen jälkeen palikka kerrallaan jos sille tulee tarvetta sen sijaan että täytyisi sitten vetää koko dedikoitu uusiksi.
Ikävästi Discourse ei niitä näyttäisi perus pollauksiin ja timingsiin palauttavan, mutta mm. etusivun latausesta ne näkyy palautuvan (löytyy network inspectorissa response-headereiden alta).
Näitä voi nyt vähän vilkuilla eri aikoihin niin saa vertailupohjaa siihen miltä ne sitten näyttävät kun taas pelataan.
Ei kannata vielä, koska taustalla höylätään (rebake) 67489 viestiä uusiksi ja konvertoidaan täyslaatuisista kuvista esikatseluversioita.
Edit:
Eli suorituskykyyn vaikuttavat parametrit ovat nyt seuraavassa asennossa.
Mitään meidän kehittämiä ja kokeilema hackeja ei ole käytössä. Ihan defaultilla mennään niiden puolesta.
Tietokantapurkki on 4-vCore / 8GB RAM resursseilla varustettu.
db_shared_buffers: 4096MB
db_work_mem: 80MB
Redis_io_threads: 3
Arvot on vedetty ihan hatusta, mutta muistin ainakin kulutus on toistaiseksi hallinnassa. Redis on se mielenkiintoisin, koska threadeja nostamalla palvelukyky kasvaa, mutta CPU kuormitus nousee. Arvasin nyt 3 threadia (ennen 2.5 versiolla tämä oli aina 1), sillä idealla että täydellä kuormituksellakin 1 vCore jää tietokantaoperaatioille ja muille prosesseille.
Fronttia pyörittävä web purkki on samanlainen 4-core 8GB värkki
Unicorns: 12
Tämä on aika iso arvo (3x vCoret), mutta ajattelin että kyllähän purkin täytyy suoriutua, koska Postgres ja Redis eivät enää kilpaile samoista resursseista. Isoimmalla 8-core purkilla taisi olla 16 kpl Unicorneja parhaimmillaan.
Muistia ei näytä frontilla juuri kuluvan
Tutkimukset jäivät siihen tulokseen, että jos Unicornien määrää on riittävä, niin yhdellä säikeellä ajettava Redis on pullonkaula. Kun tuli mahdollisuus lisätä threadeja, nousi prosessorin kuorma liian lähelle 100% järjestelmä suojeli itseään näyttämällä sivuja read-only tilassa.
Todella mielenkiintoista nähdä miten kuorma jakaantuu jatkossa.
Äkkiseltään tämä vaikuttaisi hyvältä arvaukselta. Meidän omissa järjestelmissä Google Cloudissa varataan aina kokonaan yksi core CPU-intensiivisimmille serviceille.
Sitä mietin pitkään, että laittaisinko 2 koska sekin on tuplasti enemmän kuin ennen, samalla single thread suorituskyvyllä. Vanhat mittailut kuitenkin viittasivat siihen, että chat tilanteessa Redis olisi kuormitetumpi kuin Postgres.
Otteluohjelman muutos tuli yllättäin ja huonolle päivälle - olen nimittäin tien päällä ehtoon ja vaikka ehtisinkin perille matsin aikana, niin on epävarmaa pystynkö seuraamaan kuormitusmittareita tai peliä. @ozzi:lla oli hänelläkin jotain menoa ainakin alkuillasta.
Kiinnostavaahan olisi, että hyytyykö meiltä frontti vai tietokanta ensimmäisenä. Prosessoreja on ihan saman verran käytössä kuin viime pelissä, nyt muodossa 2x4.
@a1r6 Performance headerit on päällä, eli Chromen Dev Toolsilla kuka tahansa voi tarkastella mm. Redis ja SQL viivettä, kuten @spartak tuossa jo harjoitteli.
Katselin tuossa requesteja, kun klikkaa jonkun threadin auki ja ilmeisesti nuo performance headerit löytyvät responseista requesteihin, joiden nimi alkaa numero.json, esim. 144.json?
Noiden lisäksi niitä tulee ainakin /poll?dlp=t päätteisten pyyntöjen vastauksissa. Harmi että Discourse ei pysty performance headereita toimittamaan kaikkiin pyyntöihin, mutta noillakin alkuun pääsee.
Kahdessa selaimessa auki otteluseuranta, toisessa seuraan requestien performance headereita ja niissä ei ole ollut mitään erikoista.
Mutta, nimenomaan siinä debuggeri-selaimessa yhteen requestiin tuli responsena 429 ja se jäi joksikin aikaa jumiin, toinen jatkoi päivittymistä ihan normaalisti.
Edit: Tämä siis tapahtui Tapparan ekan maalin jälkimainingeissa, sama tapahtui TPS:n maalin yhteydessä.
Edit: Äsken hyytyi tämä toinen selain joksikin aikaa, oletettavasti samasta syystä.
Edit: TPS:n tokan maalin jälkeen debuggeri-selain jäi pitkäksi aikaa jumiin ilman tuota 429:ää, kaikki performance headereiden ajat ihan normaaleja samaten kuin tuo debuggerin “Time”-columni.
Jumi loppuu automaattisesti ilman että tarvitsee tehdä refreshiä. Perstuntumalta sanoisin, että jumi kestää n. viisi sekuntia ja sen jälkeen kaikki uudet viestit tulevat kerralla.
Edit: TPS:n kolmannen maalin jälkeen jälleen debuggeri-selain jumiin ja kaikki ajat ihan normaaleja. Nyt jumi kesti kauan, ehkä n. 45 sekuntia, mutta jälleen korjautui itsestään.
Nyt näkyy suorituskysytietoja. Silloin kun Discourse niitä palauttaa, niin nämä kannattaa ainakin panna merkille: