#lurkerchangelog / No i dobra Moi Mili, czas na spowiedź! Oto, co spowodowało awarię, która poniedziałek-czwartek (do wczoraj) lagowała system tak że heeej Jak to sie mówi, człowiek uczy sie na błedach…

Temat był wyjątkowo trudny do wykrycia i analizy. Systemy zachowywały się normalnie. Sprawdziłem absolutnie wszystkie możliwe scenariusze: od przeciążenia CPU/RAM (htop), po przeciążenie dysków (iotop), przez analizę ruchu sieciowego, profilowanie pakietów, ograniczenia połączeń: ilości (limit conn), wsadów (body size), timeoutów (w tym rownież proxy_connect_timeout) i tysiąc innych rzeczy. Widziałem ogrom ruchu na GET /socket. Burst-limity załatwiły sprawę, ale problem pozostał. (tu się okazało, że na niektórych urządzeniach, głównie Mac oraz iOS, apka ignoruje timeout miedzy kolejnymi próbami nawiązania połączenia, gdy serwer zamyka socket i próbuje non-stop odnowić połączenie, aż do skutku - co b. mocno mnie zmyliło). Esz, cieżkie to były 3 dni, naprawdę.

Tak więc odpowiadam, co wywaliło cały system. W apkach nie robi się każdorazowo połączenia i rozłączenia z bazą, gdy idzie request (bo to mocno spowalnia, trzeba by wykonywać każdorazowo handshake'a itd.) - zamiast tego korzysta się z tzw. poola, czyli puli, która trzyma określoną liczbę klientów.

const pg = require('pg');
const pool = new pg.Pool(config);
let client = await pool.connect();
…
await client.release();

Pool wydaje klienta, kiedy trzeba. Po "robocie" klient wraca do poola, gotów do kolejnych akcji. I tak w kółko. Lurker korzysta ze sterownika node-postgres, w którym domyślna liczba owych klientów w poolu wynosi… 10! Co trzeba koniecznie zmienić, podbijając moocnooo w górę. Otóż jakimś nieumyślnym cudem zakomentowałem ten parametr i liczba klientów w poolu spadła do wartości domyślnej, czyli 10. Co powodowało laga, bo jeśli wchodzili nowi ludzie, to musieli czekać aż zwolni się klient: można to przyrównać do stania w kolejce. Masz 10 kas w sklepie i ustawiasz się do jednej z nich i czekasz. 4 workery dają 4 sklepy, w każdym po 10 kas, ale to nadal za malo sklepów i kas - coś jak Carrefour przed świętami (ruch idzie cały czas w górę).

No i to tyle. Przepraszam wszystkich, że dałem ciała. Chochlik w kodzie, jak to sie mowi. Można robić memy, zapraszam! (bana nie będzie!)

Podsumowując, problem był wyjątkowo ciężki do wykrycia. Wiele rzeczy tutaj mnie zmyliło. Jako ciekawostkę dodam, że lurker był w przeszłości dwa razy ddosowany (nawałem pakietów z botneta) i nawet tego userzy nie odczuli za bardzo, bo całość skończyła się po 2 minutach. Dlaczego? Ano dlatego, że lurker podnajmuje hosting u Hetznera (TOP 6 najwiekszych dostawców). Jeśli ktoś rozpoczyna ddos na jakąś maszynę, wpływa to bezpośrednio na stabilność całej sieci u dostawcy, dlatego bardzo sprawnie wycina on na głównym routerze podejrzany ruch (to leży także w jego interesie). Ja natomiast - jako admin (ich klient) - dostaję maila z info, co właśnie sie dzieje i że zaraz zostanie sprawa załatwiona. Jest to bardzo kompleksowa obsługa i bardzo fachowa, monitorowana 24h na dobę. Tak więc na tem moment CloudFlare nie jest potrzebny

Od jutra wracam do kodzenia. Mam sporo zaległości, bo praktycznie cały tydzień w plecy. Ale spokojnie, nadrobimy