Kärppämäistä oveluutta. Tämän itse asiassa (muistaakseni) pystymme tekemään, eli näyttämään alueen vain rekisteröityneille.
Vaikea sanoa onko sillä vaikutusta. Tätä tutkiessa katselin jonkin pelin aikana, että väkeä oli paikalla n.250.
Historiallisesti se ei ole iso määrä, sillä Kipinöissä on saavutettu 450, ennen kuin puhti loppuu. Toisaalta Kipinöissä viestit eivät tule aivan niin yhtäaikaisesti kuin kiekkopelissä (maalit ja muut tilanteet).
Näitä on ainakin itsellä joskus vaikea analysoida. Meidän järjestelmissä (pyörivät Kubella Google Cloudissa) on alkanut esiintyä semmoista ongelmaa, että requestit jotka normaalisti vievät 0.5s kestävätkin 1-10s. Kun aiheeseen liityvät servicet restartataan, palataan takaisin 0.5s tasolla.
Ennen restarttia muisti ei lopu, mutta CPU:n käyttö on tapissa, eikä olla vielä keksitty että miksi.
Pitäisikö katsoa antaako DISCOURSE_ENABLE_PERFORMANCE_HTTP_HEADERS lisäselvyyttä pullonkaulaan? Se voisi antaa jonkinlaista osviittaa jo vaikka ei pelejäkään käynnissä. Redis ja PostgreSQL olisi mielenkiintoista nähdä millaisia aikoja ne käyttää.
Periaatteessahan siinä voi olla että esim. rate limit dataa kertyy Redisiin paljon ja jonkun nyanssin takia se aloittaa yskähtelyn hetken jälkeen (vähän kuin @bastardo on huomioinut).
Postgren ja Redisin lokeja voisi olla myös hyvä vilkuilla. Sieltäkin voisi periaatteessa jotain osviittaa löytyä mikä saa Discoursen niiaamaan.
Me hostataan postgresit aivenissa ja niillä on tosi hyvät työkalut logien kyttäämiseen ja kyllä sieltä säännöllisen epäsäännöllisesti jotain yllätyksiä löytyy, kun joku muistaa tarkistaa.
Ihan mielenkiinnosta, mikä se ongelma oli, kun se on nyt ilmeiseti saatu ehjättyä?
Ei ole saatu. Kyllä jumeja tuli, mutta käyttäjälle vähän “siistimmin” kuin aikaisemmin.
Olen edelleen taipuvainen uskomaan, että v2.4 tai 2.5 päivitys on tuonut ongelman mukanaan. Jotenkin vaikea uskoa että 7kk orgaaninen kasvu tietokannassa olisi romauttanut suorituskyvyn näin totaalisesti.
Paremman datan saaminen edellyttäisi hyvää logitusta, sekä tietysti kykyä ymmärtää datan mahdollisesti antamat vihjeet.
Pukkaa ensi viikolle luutavasti pitkää työreissua, joten en ole varma paljonko tähän ehtii paneutumaan. Jatkotoimia on kuitenkin ainakin kaksi mitä voi kokeilla.
No me ollaan itseasiassa juuri tällä viikolla setvitty kantaongelmiakin, jostain syystä kaikille tauluille ei ole ajettu auto vacuumia ja kantojen viemä levytila on lisääntynyt huomattavasti nopeammin kuin pitäisi datamäärän lisääntymiseen verrattuna.
Kantoja on nyt sitten tällä viikolla siivottu käsin (ajettu esim. vacuumia manuaalisesti) ja saatu tilanne taas paremmaksi.
Muutaman viikon päästä pitäisi tulla Postgres-päivitys, jonka yhteydessä kannan pitäisi kutistua. Muuten se ei (mutu) näytä mitään hirveän isolta, mutta post-timings on hulppeat 20GB.
Pitääpä erikseen kiittää, sillä sain tuosta ajatuksen! Postgres 12 päivitys tuli versiossa 2.5 ja siihen on suositeltu, mutta ei pakotettu, tietokannan huoltoja päivityksen jälkeen.
Ajelin aamukahvin lomassa tietokannan vacuumin ja reindexin. Ne menivät läpi ilman virheitä, eikä mitään ihan valtaisaa tauhkaa löytynyt mutta post-timings pieneni kuitenkin ~4GB verran. Se on edelleen tosi iso, mutta tuo on jo sellainen määrä jolla voi olla vaikutusta johonkin.
Joku saattoi huomata sivujen olevan vähän aikaa vain lukutilassa (@Varilasit).
Kuinka paljon post_timings -taulun indexi vie tilaa?
./launcher enter app
su - postgres
psql discourse
SELECT pg_size_pretty(pg_indexes_size('post_timings'));
Tuolla saisi vähän lisätietoa kuinka post_timingsin koko vaikuttaa indexiin. Sekin voi olla että Discoursen käyttämä 4GB (oletusasetus) Postgresin effective_cache_size:lle ei enää riitä (todella mojovaa mutua/arvailua).
Muitakin SQL-tauluja voi olla joiden indexi on suuri, mutta isoimmasta taulusta on aina loogisinta aloittaa.
Tilannepäivitys.
@spartak kyselit taulun kokoja
| table_name | row_estimate | table_size | index_size | total_size |
|---|---|---|---|---|
| post_timings | 140654064 | 6149 MB | 10 GB | 16 GB |
| topic_views | 12913334 | 624 MB | 1467 MB | 2091 MB |
| posts | 851047 | 847 MB | 370 MB | 1216 MB |
| user_actions | 4384010 | 333 MB | 870 MB | 1203 MB |
| post_search_data | 834192 | 755 MB | 349 MB | 1104 MB |
Lisäksi beta 6 versiossa on tällainen suorituskykymuutos:
Vähän kuten pelkäsinkin, ei tämä merkittävästi lisäraudalla parantunut. Muistin määrä tuplattiin ja CPU ytimiä tuli 33% lisää. Tuon muistin takia halusin tämän kokeilun tehdä, koska epäilin mahdolliseksi syyksi isoksi kasvaneen tietokannan suorituskykyä.
Asiaa voi tietysti lähteä ratkomaan paremman logituksen kautta. Tähän saisi Prometheus -pluginin, mutta tiedä sitten löytäisikö sillä viisasten kiveä. Joka tapauksessa virhe pitäisi tosi hyvin pystyä osoittamaan, ennen kuin kehittäjät siihen tarttuvat.
Metan puolella jäsen Falco heitti, että Redis saattaisi muodostaa meidän tapauksessa pullonkaulan. Heillä on omassa tuotannossaan jo Redis 6 ollut pitkään ajossa, mutta kaikelle kansalle se tulee 2.6 version mukana.
Me saatiin ja otettiin se nyt etupeltoon käyttöön:
* `base_image: discourse/base:2.0.20201120-0306`
* `redis_io_threads: "4"`Sitten kysymys erityisesti jäsenille @spartak ja @ozzi, tai vielä tuntemattomille admin velhoille: Onko Prometheus.io tuttu?
Discoursen saa pluginilla tuottamaan metriikkaa Prometheukselle, mutta se data pitäisi saada sitten visualisoitua. Sen avulla pystyisi näkemään missä viive tapahtuu, kun live-chat jumahtaa.
Ihan sivusta kommentoituna, itse käytämme duunissa Grafanaa ja ollaan liitetty siihen myös hälytysten lähettäminen Slack-kanavalle, jos tulee jotain ongelmaa.
Lisäksi Postgres hostataan Aivenissa, ja siellä on hyvät työkalut sen tonkimiseen, että jumittaako kanta.
En ole Prometheusta käyttänyt mutta vastaavia tuotteita kyllä. Näillä kyllä monesti näkee jumitukset, muttei niiden syytä. Helpompi voisi olla tuo @Spartak mainitsema DISCOURSE_ENABLE_PERFORMANCE_HTTP_HEADERS, joka kertoisi odotellaanko siellä Redistä, Postgressia vai viestijonoa.
Prometheus ei ole tuttu, mutta näyttää tosiaan siltä että plugarin tuottaman datan sillä saa piirrettyä nätisti kartalle. Sitä lienee jotenkin voinee säätää kuinka usein uutta dataa Discoursen alta haetaan jne. Se ei itselle selvinnyt mitä kaikkea sillä tarkalleen ottaen saa monitoroitua. SQL ja Redis näyttäisi olevan, mutta @ozzi n mainitsema message bus myös hieman kiinnostaisi.
Hieman työläämmältä se näyttää (tarvitsee pluginin sekä itse Prometheus-palvelimen) kuin performance headers. Toisaalta, jos sitä kehittäjät suosittelevat, niin se on aina aika vahva signaali.
Jos toi Prometheus toimii niin kuin Grafana ja kumppanit niin ei se kummoistakaan virtuaalikonetta tarvitse piirtääkseen käppyrää. Itse työnhän tekee pääosin kantapalvelin, josta toi kyselee dataa.
Ei ole ehtinyt logituksia tunkkaamaan paikalleen, mutta alkaa käymään melko selväksi, että Redis muodostaa meidän konfiguraatiossa pullonkaulan.
Tämä näkyy paremmin kun laitettiin versio Redis 6 tulille, joka kyllä parantaa kykyä puskea viestejä eetteriin, mutta CPU-kuormat alkavat hetkittäin nousemaan 100% rajalle.
Näillä näkymin muutamme Discoursen itsensä hosting palvelun piiriin. Ovat tarjonneet alennettua hintaa, jotta pääsevät pönkimään meidän käyttötapausta ja saavat siitä dataa.
Tätä ennen tehdään pieni testiajo Hetznerin dedicated palvelimella. Lyhyesti 1-2 peliä, että näen/nähdään mikä on toimivuus. En usko että yhteistyömme Discoursen kanssa on ikuista, joten pitää olla plan-B selvillä.
Eli lähitulevaisuudessa tulee huoltokatkoksia pelien välissä, mutta niistä ei ole syytä huolestua.
Edit: Tämä tapaus on paljastanut, että meillä on yllättävänkin paljon sysadmin osaamista täällä yhteisössä. Myös @Luppakorva ilmoittautui alan mieheksi. Foorumi tuntuu olevan nykyään sen verran iso ja suosittu, että infran rakentaminen alkaa olemaan haaste. Tätä pitäisi ehkä osaavalla joukolla miettiä ja toteuttaakin yhdessä. Lisää osaamista ja toisaalta huoltovarmuutta, jos me @ozzi:n kanssa saadaan korona tai ei kuulla Hämpillä kiitävää ratikkaa.
Allekirjottautunut auttaa kyllä ilmanmuuta minkä pystyy jos apua tarvitaan. Ei muuta kun viestiä vaan jos tarvetta tulee.