Titokzatos jelenések

Digitalocean szerver, már több éve fut probléma nélkül Ubuntu 16.04-el.
Időről időre vesszük elő és deployolunk rajta projekteket (értsd weboldalakat), napi 40E látogatószám mellett futnak ilyenkor pl nyereményjátékok esetén.

Örökölt projekt, örökölt kód, szpunk vele, mint akinek az a dolga.
Először a facebook api korbácsolta fel a kedélyeinket, mikor beindult a forgalom a "Call count" szám felment 2-300%-ra és bannolt bennünket Cukkemberg bácsi és javasolta, hogy bánjuk csínján a graph api query-kel.
Évek óta ez a kód fut, eddig nem volt gond. Nem baj, biztos módosítottak a használati feltételeken, csak mi éltünk kő alatt, optimalizáltunk.
Még úgy sem volt tökéletes.
Így gondoltuk kiírtjuk a facebookot az oldalunkról, mert csak a baj van vele - ekkor láss csodát a call count számláló leesett 0%-ra és mind a mai napig úgy áll 5x forgalom idején is.
Legjobb tippünk: a fb ekkorra skálázott fel és kvázi bemelegedett az apink. Vagy kiakadt és tönkrement a számláló. Fene tudja. Lehet a fb rendszere volt kaksi, de természetesen semmi tájékoztatást nem kaptunk az esetről.

Ám boldogságunk nem tartott nagyon soká, ma, egy hét elteltével most a Mailgun szólt ránk, hogy túl magas a bounce rate-ünk, azaz sok a regisztráció során tévesen megadott email így mivel nem létezik az email cím visszapattan.
Az érdekesség az, hogy korábban ezzel sem volt gond/figyelmeztetés. Nézve az adatbázist nincsenek hülyeségek felvíve, valószínűleg csak elírja a paraszt a mail címét, ebből jön fel a bounce rate-ünk.
Mivel visszaigazolás nélkül a szájbavert regisztrációnk sem igazán működik így felvettem egy hibajegyet ahol leírom tételesen, hogy mi a gond és mit tudtunk mi tenni és légyszi engedélyezzék újra az account-ot, mert a levelezéstől függ a mi nyereményjátékunk.
Nem tették, nyilván nem, visszaírt Ashley, hogy ezt és ezt és ezt írjuk neki le és tegyük meg az óvintézkedéseket - mintha el sem olvasta volna a jegy szövegét (amit korábban írtam neki). Sebaj, valszeg reggel óta visszaböfögött üzenetükkel elvannak megint egy napot és megint nem lesz egy ideig rendes regisztrációnk.

Nade menjünk tovább.
Digitalocean szerveren ($20) megy az oldal. Figyelem a projekt élesítésekor, hogy a react "fordítója" érzésre úgy 4-5x annyi ideig gondolkozik, mint szokott. De gondoltam, hogy hátha csak valami olyan apróság az okozója, mint 1-2 plusz plugin és ezért tart hosszabb ideig a deploy.
Egy nagy lóf*szt! Tettem fel munint, hogy lássuk hogy alakul a szerver és nem-e kellene bővíteni erre meglátok egy olyan változót a cpu használatban amit - bocsássatok meg, valszeg túl fiatal vagyok - még soha az életben nem láttam: "steal". Csak nekem újdonság ez? Valaki felhomályosítana, hogy mi a tököm lenne ez és miért tesz ilyen a DO?
KÉP

Természetesen ez is titokzatos módon megszűnt kb egy napos pörgés után, azóta a load sokkal lejjebb van, láss csodát újra gyors a deploy.

Heti rage-em végére érve - ami miatt nem tudtam az utóbbi időkben nyugodtan sem aludni- csak egy kérdésem maradt:
Ekkora divat lett manapság kummantani a szolgáltatóknak?
Ha limitet vezetnek be valamiben nem illene szólni előre?
Csak bannolni a fenébe és majd jól megtanulja a paraszt?

Hozzászólások

Steal az arány amit a virtuális processzorod a valós proceszorra vár, hogy kiszolgálja azt.
0% mikor az adott vason, minden virtuális gépet a neki kiosztott arányban szolgál ki a valós proci. Az-az minden virtuális gép annyi CPU ciklust kap amennyi jár neki. Ha ez nullánál nagyobb, akkor a virtuális gépednek időnként szólnak, hogy most pofa be és várj egy kicsit. 100% mikor baszik dolgozni az egész és áll a virtuális géped, mint a 486-os a befagyott win95-el.
Hogy miért magas a steal értéked, ahhoz látni kellene a többi vm-et is, vagy ugyanazt a vm-et kellene futtatni több hoston.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

A cpu steal elég gyakori cucc felhőben, általában ugyanazon hypervisoron mint amelyiken a te géped is hostolódik fut olyan gép ami eszi a CPU-t. Próbálj gépet váltani, ezt nem tudom hogyan kell Digital Ocean-on, de Amazonon úgy kell hogy kikapcsolod a guest-et és mikor újraindítod akkor egy másik hypervisoron fut fel. Ezzel probléma megoldva míg ismét kapsz egy zajos szomszédot, vagy kifizeted az extrát és kapsz dedikált hypervisort.

Munin mellé azért felraknék pár APM cuccot csak hogy tudjam mi hajtja meg a szervert. Nézz rá a Data Dog, New Relic, Prometheus, ElasticSearch kombókra (utóbbi természetesen külön vas).

-