Am avut de 4x blocări acum ale serverelor AWS ERP din cauza memoriei care aparent se termină la maxim și a sistemului, practic, murind cu 100% CPU și fără [puțină] RAM disponibilă.
Ubuntu 18.04.5 LTS (GNU/Linux 5.4.0-1060-aws x86_64) (AWS AMI)
Acest lucru a avut loc de trei ori în mijlocul unei acțiuni GitHub. Acțiunea făcea un import al bazei de date și apoi o notificare de slăbire. Ați crede astfel că unul dintre acești pași a cauzat problema, dar în mod ciudat, pașii s-au finalizat toți în mod normal. Baza de date a fost în regulă și notificarea de slack a fost împinsă.
GitHub în sine a pierdut legătura cu alergătorul, iar memoria virtuală a trecut prin acoperiș chiar și după ce acțiunea a fost finalizată.
A patra oară s-a întâmplat în timp ce NIMIC rula. Serverul era de fapt inactiv și nu se întâmpla nimic.Totuși, nu am niciun jurnal sau capturi de ecran „de sus” cu ACEA, dar am prins-o pe loc o dată:
Deci, sistemul este o VM AWS cu 4G de RAM. Rețineți că cred că SI care a configurat acest sistem a configurat fără spațiu de swap. Acest lucru este, fără îndoială, corect [foarte sigur] pentru un server, în sensul că, dacă există o scurgere de memorie, doriți ca sistemul să raporteze lipsa memoriei și să ia măsuri corective, deoarece, în cazul unei scurgeri de memorie, oricum veți muri în cele din urmă.
Pe termen scurt, mi s-a cerut doar să dublez RAM. Acest lucru este oarecum inutil, deoarece este un sistem foarte puțin încărcat (în mod normal, rulează cu doar aproximativ 2 G de RAM în uz atunci când se face o muncă grea pe loturi) și, sincer, dacă GitHub Runner.Worker atinge maxim 7 GB de RAM pe un sistem de 4 GB, de ce nu ar ajunge maxim la 16 GB de RAM pe un VM de 8 GB, dar vom vedea dacă se blochează din nou. Nu sunt contrariat să schimb configurația de swap a TFG, dar nu sunt sigur că este o soluție
Am raportat acest lucru la GitHub, dar după > 3 săptămâni de inacțiune m-am gândit să verific aici și să văd dacă cineva are idei sau remedieri.
Mulțumesc,
== Ioan ==
