Prijava neobičnih kvarova - hitno i bitno!

[drug mile]

Ne vidim trenutno nikakav problem, forum funkcionira (za moj pojam) besprijekorno. U zadnje vrijeme, kada imam ogroman, dosadan posao, uvalim ga Chat GPT-ju. Nekad mi nađe sitnice u kodu koje meni promaknu, pruži mi savjete kako nešto optimizirati, a nekad i totalno zabrije i krene dirati stvari koje nikako ne bi smio dirati. Nemam ideju, doduše, kako ga iskoristiti u ovom konkretnom slučaju, ali možda bi on imao.

[Stitch]

Jučer mi se nekoliko puta na ekranu pojavio 500 Internal Server Error, što je obično znak da skripta nije uspjela obaviti posao dokraja, bilo zbog malo memorije bilo zbog malo vremena. Alati kojima se služim prilično su zahtjevni, a što je najgore - rizični su jer mogu sjebati bazu toliko da se ne može popraviti. Zato uvijek imam bekap. No žao mi ga je upotrijebiti jer je određenih pomaka ipak bilo. Kvaka 22.

[drug mile]

Da li ti je danas nešto čudno javljalo? Pokušao sam se par puta ulogirati, bez uspjeha.

[Stitch]

Ne, ali moguće da si naletio dok se vrtjela skripta, što troši sve moguće resurse. Vidim li gdje neparsirane BB kodove, znam je pokrenuti i danju, dok mogu komunicirati s hostingom. Uveli su mi bili neka ograničenja jer im tjeram server u crveno.

Parsiranje sada ide dio po dio, jednostavno zato što u suprotnom dobivam 500 Internal Server Error. Koliko će trajati, nemam pojma. Vjerojatno ću ovaj tjedan završiti. Ako mi hosting prije toga ne ukine korisnički račun.

[Stitch]

(...) Pokušao sam se par puta ulogirati, bez uspjeha.

Prije nekoliko minuta nakratko sam zatvorio forum, dok se ne obave potrebne aktivnosti. To ću činiti i ubuduće, da se ne ponavljaju današnje epizode s logiranjem ili pisanjem.

[admin]

Alati kojima se služim prilično su zahtjevni, a što je najgore - rizični su jer mogu sjebati bazu toliko da se ne može popraviti.

Štošta se i može srediti, ali napati se čovjek kao Isus na križu.

Mislim da sam obrisao oko 3000 redaka viška nastalih u SQL tablicama. I to po čudnome ključu: normalne teme pretvorene su u ankete, s naslovima ili udvostručenima ili uklonjenima; znakovi koji su funkcionirali u phpBB-u 3.0.x i 3.1.x pretvoreni su u inačici 3.2.11 u neobične simbole itd. Izgubio sam noć da nađem odgovarajući query za svaki pojedini slučaj jer nije imalo smisla da ručno ispravljam toliku količinu podataka.

Uglavnom, prisjelo mi parsiranje postova.

[admin]

I da, malo ću stati s tim, trebam predah.

[Stitch]

Čekao sam da server završi s bekapiranjem instalacijâ kako bih još štošta provjerio, usput zavirivao na portale i čituckao knjige, a sad kad mogu raditi - ne da mi se.

Rekao bih da je popravljanje baze podataka uspjelo, riješili smo se viškova koje je za sobom ostavio alat za parsiranje postova, a kako trenutačno nema boljega, ostaje mi da strpljivo čekam dok ne programiraju aplikaciju primjereniju našem forumu. Od inačice 3.0.x (mislim da sam zatekao phpBB 3.0.12 kad sam se prihvatio ovoga posla) do sadašnje 3.2.11 bilo je mnogo ažuriranja - više od dvadeset, čini mi se, i to bez ekstenzija! - a mnogo ažuriranja znači i mnogo potencijalnih komplikacija. Zato se ne treba čuditi što developerski alati nekima pomognu, a nekima odmognu. Instalacije su poput ljudi, svaka je drukčija. Konfiguracija servera, plugini, preinake predložaka i ostalih datoteka - sve utječe na rezultat.

[admin]

Već mi se dvaput dogodio SQL Error dok sam objavljivao post - bilo je prolazno, doduše - pa molim da mi prijavite ako se i vama pojavi bijeli ekran.

Hosting veli da je takvo što moguće kad/ako dođe do preopterećenja servera, a ne pomaže ni NVMe disk, koji čini upite bržima, ali omogućuje više paralelnih zahtjeva. Drugim riječima, kad nekoliko PHP procesa dođe do MySQL-a istovremeno, server prijavi pogrešku - što je paradoksalno jer NVMe RAM služi upravo da ubrza stvari.

Optimizirat ću tablice i provjeriti sustav, ali to, sve u svemu, ne bi trebao biti (pre)velik problem. Dogodi li se, kliknite strelicu za natrag u pregledniku pa ponovite što ste radili. I zovite admina.

[Pastir]

Meni zasad sve dobro radi.

[Stitch]

Postimages povremeno puca, fotografije se katkad prikazuju, a katkad ne - što načelno brzo rješavaju. Vidjet ćemo koliko će im trebati ovaj put.

[Pastir]

Forum je već dva-tri sata neuobičajeno spor, a noćas je sve bilo OK.

Što se događa?

[drug mile]

Forum je već dva-tri sata neuobičajeno spor, a noćas je sve bilo OK.

Što se događa?

Isto i meni

[Stitch]

DDoS napad (distributed denial-of-service), što znači da serverske resurse troši golem broj botova. Ovako je recimo trenutačno na našoj domeni:

New posts 28 • New topics 1 • New users 0
In total there were 33123 users :: 5 registered, 28 bots, 2 hidden and 33088 guests active over the last 24 hours

Na drugima je slično, sve su instalacije zatrpane i zagušene. Nema tu pomoći, možemo jedino čekati. No proći će. Uvijek prođe.

[Stitch]

Sad bi trebalo biti bolje, baza je optimizirana, a dio sustava reinstaliran.

[Pastir]

Zvuči komplicirano. Što radiš u takvim slučajevima (ne tvrdim da ću shvatiti)?

[Stitch]

Najprije, promijenio sam engine baze podataka. Prelaskom glavnih tablica na InnoDB neke posljedice opterećenja postale su manje opasne za bazu i forum. Najveća je razlika kod zaključavanja. MyISAM zaključava cijelu tablicu pri pisanju. Ako primjerice pod velikim prometom mnogo zahtjeva pokušava pisati u phpbb_sessions, phpbb_posts, phpbb_topics, phpbb_users, ACL i tracking-tablice..., MyISAM može stvoriti red čekanja: jedan zapis blokira druge, oni čekaju, zauzimaju procese, a onda forum počne djelovati kao da je potpuno pao.

Kod InnoDB-a zaključavanje je uglavnom na razini redaka. Dakle, jedan korisnik koji mijenja svoj session ili tracking-podatak ne mora blokirati cijelu tablicu za sve ostale. Zato sam na InnoDB najprije prebacio phpbb_posts, phpbb_topics, phpbb_sessions, phpbb_sessions_keys, phpbb_topics_track, phpbb_forums_track i phpbb_notifications. To nisu slučajno odabrane tablice. Pod najvećim naletom zahtjeva upravo su sesije, praćenja i sadržaj foruma kao potencijalne točke velikog broja paralelnih čitanja i upisa.

Onda, Tapatalk, koji je posebno nezgodan jer normalni web-posjetitelj ima predvidiv obrazac: otvori stranicu, pročita, eventualno odgovori i ode. API/klijentski promet može biti mnogo složeniji: zahtjev, odgovor, novi zahtjev, novi zahtjev, sinkronizacija, autentifikacija - pa sve ispočetka. Ako botovi otkriju takav endpoint, mogu ga bombardirati bez potrebe da prolaze cijelo forumsko sučelje.

Zato Forum.hr ima recimo Cloudflare, koji napravi ono što ti kao administrator zapravo ne želiš raditi ručno - filtrira promet prije nego što stigne do PHP-a i MySQL-a. No cijena je toga korisničko iskustvo jer umjesto klik - forum dobiješ klik - Cloudflare-provjera - čekanje - možda još jedna provjera - forum. Za običnog korisnika to je iritantno; za korisnika koji dolazi preko Tapatalkova automatiziranoga klijenta može biti još problematičnije jer WAF (firewall) katkad ne može jednako lako razlikovati legitimni od automatiziranog prometa. I tu se vraćamo na ono što sam jučer i danas napravio s bazom: InnoDB može smanjiti štetu kad promet ipak dođe do aplikacije, ali ne rješava problem na ulazu. Cloudflare/WAF/rate limiting rješavaju drugi dio problema. Zapravo bi idealna obrana bila slojevita: internet - WAF/rate limiting - web-server - PHP/phpBB - InnoDB, a ne očekivati od MySQL-a da obrani forum od prometa koji uopće nije trebao doći do njega.

Kako god, nakon prilagodbe i optimizacije baze te instaliranja izdržljivijega Tapatalka i sigurnosnoga softvera forum je sada otporniji na legitimne nalete prometa, botove koji stvaraju mnoštvo paralelnih zahtjeva i neke oblike aplikacijskoga DoS-a. Otporniji međutim ne znači savršeno zaštićen. Toga nema.