Puncte:4

Este acest server supraîncărcat (capturi de ecran htop)

drapel bd

Nu sunt un tip server, cred că pare supraîncărcat, dar nu sunt sigur. Ai spune că acest server este supraîncărcat? introduceți descrierea imaginii aici

drapel jp
Da, este supraîncărcat, încărcarea medie este prea mare pentru două procesoare
Jack0220 avatar
drapel bd
Mulțumiri. Ar trebui să faceți din asta un răspuns, astfel încât să puteți obține credit. @AlexD
Criggie avatar
drapel in
@Jack0220 Este aceasta o mașină fizică sau o mașină virtuală? Întreb pentru că o mașină fizică cu 2 nuclee ar fi probabil să devină puțin vechi acum (astfel înlocuirea devine mai importantă), în timp ce o mașină virtuală poate fi adesea mărită cu nimic mai mult decât o repornire (și, posibil, o lunară mai mare dacă sunteți în AWS sau similar)
Craig Estey avatar
drapel kr
Ai o mulțime de fire/procese. _Dacă_ puteți restructura aplicația/serverul și fiecare solicitare este „ușoară”, este posibil să puteți implementa un „pool de fire”. Adică, suprasarcina de creare/aderare a unui fir este mai mare decât procesarea pe care o face. Serverul definește un grup de N fire de execuție (de exemplu, unde N este numărul de nuclee * 2). Serverul pornește firele. Poate pune cererile la o coadă comună. Fiecare fir preia o solicitare din coadă, o procesează și apoi face bucle/sleeps în coadă, așteptând mai multă muncă. Altfel, doar „cheltuiește banii” ;-)
James avatar
drapel in
„Acest *server* este supraîncărcat”? Imposibil de spus din datele furnizate. Ce software rulează și depinde în mare măsură de CPU, etc. Lucrurile merg încet sau ești de fapt ok la vârf? La fel și resursele necesare sunt satisfăcute, deși cu resursele disponibile la maximum. Acesta din urmă este „în general” nu este bun, deoarece ar trebui să aveți o suprasarcină pentru când ceva are nevoie de mai mult decât este planificat sau are nevoie de obicei etc. „Este acest *CPU* supraîncărcat” nu, este la utilizare maximă.
Puncte:12
drapel jp

Serverul dvs. are doar două procesoare și LA (încărcare medie) în intervalul 10-15. Aceasta înseamnă că procesele care rulează necesită mai mult timp CPU decât poate suporta CPU-urile. Puteți citi mult mai multe despre LA în Acest articol de Brendan Gregg.

Vă rugăm să rețineți că LA este doar o singură măsurătoare și, deși sistemul dvs. nu primește tot timpul necesar procesorului, este totuși posibil să primească suficient timp CPU pentru a servi în mod rezonabil solicitările utilizatorilor finali. Trebuie să vă verificați celelalte valori înainte de a lua orice decizie cu privire la acest server, dar dacă utilizatorii dvs. se plâng deja, atunci soluția este clară - obțineți o instanță cu mai multe procesoare.

Jack0220 avatar
drapel bd
Apreciez asta. Sistemul continuă să ajungă la vârf. În general, poate face față sarcinii, dar nu în timp util. Adesea, serverul nu răspunde sau răspunde prea târziu. Mi-ai confirmat suspiciunea.
marcelm avatar
drapel ng
_"Serverul dvs. are doar două procesoare și LA (media de încărcare) în intervalul 10-15."_ - Și totuși, 2 din 3 capturi de ecran arată că utilizarea procesorului este de aproximativ 60%. Nu aș fi atât de repede să judec că serverul este legat de CPU. Ar putea fi legat de I/O. De asemenea, văd o presiune relativ mare a memoriei, care ar putea să nu ajute situația I/O. Și oricum, o sarcină mare nu înseamnă că un sistem este supraîncărcat în sine. Un server bine utilizat, care nu este sensibil la latență (de exemplu, e-mail) poate fi perfect cu sarcini mari. Depinde de situație.
Guntram Blohm avatar
drapel in
Totuși, nu există un singur proces în modul D și (o parte din) redis pare să consume 100% CPU (ceea ce înseamnă că are un singur thread sau ar depăși 100%). Ceea ce ar putea însemna că totul așteaptă redis (destul de suprasolicitat), iar adăugarea de nuclee nu va ajuta prea mult aici. Aș verifica fișierele de configurare și jurnal redis înainte de a arunca mai multe nuclee la problemă.
drapel jp
@marcelm Sunt de acord că ar putea exista o încărcare I/O semnificativă din cauza rulării „redis-rdb-bgsave”, dar este greu de spus, deoarece nu există nicio statistică iowait disponibilă și niciun proces cu starea „D”. Vă rugăm să rețineți că pentru fiecare captură de ecran 1 min LA este mai mic de 15 min LA, deci este puțin prea lung pentru un instantaneu de 2 GB.De asemenea, cea mai mare parte a timpului CPU este cheltuit în procesul `chirpstack-network-server`.
drapel jp
Deoarece sistemul rulează pe AWS, aș recomanda mutarea „redis” la o instanță gestionată ElastiCache Redis, dar acest lucru va introduce o întârziere suplimentară în rețea care poate afecta performanța sistemului.
Jack0220 avatar
drapel bd
Vă mulțumim tuturor pentru contribuția suplimentară. Acesta este un server de rețea LoRa și este sensibil la latență. Există downlink-uri ca răspuns la uplink-uri care trebuie să fie livrate foarte repede și ceea ce văd este că adesea vin prea târziu și uneori nu vin deloc. Uplink-urile sunt sporadice, așa că este posibil ca o grămadă de ele să se întâmple în același timp, ridicând sistemul. @marcelm Guntram Blohm
Puncte:10
drapel mx

Definiți „supraîncărcat”.

Dacă mergeți doar după medie de încărcare, atunci da, este supraîncărcat (cu un factor de aproximativ 5-7,5). Cu toate acestea, încărcarea medie este doar o măsură rezonabilă de utilizat dacă volumul de lucru este masiv paralel și în principal legat de CPU. Load average urmărește în esență numărul mediu de procese care ar putea rulați în ultimele 1/5/15 minute.

in orice caz, pe baza a două dintre capturile de ecran, utilizarea instantanee a procesorului nu este în mod constant 100% din ceea ce este capabil sistemul. Acest lucru, combinat cu o medie de încărcare mare, înseamnă că multe procese trebuie să ruleze, dar acestea rulează rapid și apoi sunt gata. Acest lucru este destul de normal pentru un sistem care oferă servicii de rețea, așa cum sunt majoritatea serviciilor de rețea nu Legat de CPU, dar în schimb legat de IO. Aceasta înseamnă că încărcarea medie nu este o măsură bună pentru a determina utilizarea resurselor pe sistem.

La ce ar trebui să te uiți cu adevărat aici (și de fapt, la ce ar trebui să te uiți mai întâi orice serviciu de rețea) este metrica de performanță a serviciului în sine.În cele mai multe cazuri, cele relevante sunt măsurătorile latenței pentru diferitele tipuri de solicitări pe care le servește serviciul (și, mai precis, de obicei doriți să vă pese de latența medie și una dintre percentilei 95 sau 99 sau latența de vârf). htop pur și simplu nu pot urmări acest lucru pentru tine, trebuie să te uiți la un alt instrument, cum ar fi Netdata (exonerare de responsabilitate, lucrez pentru Netdata) sau Prometeu.

Mai bine decât atât: utilizatorii raportează probleme? Dacă răspunsul este nu, nu există probleme raportate, atunci probabil că este irelevant dacă serverul este „supraîncărcat” sau nu, pentru că totul funcționează suficient de bine.

drapel jp
Procesele legate de rețea nu afectează `LA`, așa că nu veți obține `LA` > `număr de procesoare` pe sistemele legate de rețea IO. Când `LA` > `n CPU-uri` înseamnă că există o mulțime de procese care așteaptă CPU, dar nu pot rula, nu că "ele rulează rapid și apoi sunt gata" (în acest caz, veți obține LA aproximativ același număr de procesoare) . LA ridicat înseamnă că sistemul **este** legat de CPU sau de disc IO. „CPU-ul instantaneu nu este constant 100%” înseamnă că sistemul a trecut de vârful de încărcare, îl puteți vedea de la 1m LA fiind mai puțin de 5 și 10 minute LA.
Jack0220 avatar
drapel bd
Da, există probleme cu serviciul final, serverul nu răspunde întotdeauna suficient de rapid. Există link-uri în sus și unele dintre ele necesită link-uri în jos ca răspuns. Latența legăturii în jos depășește uneori 5 secunde, ceea ce este mult prea târziu (acesta este un sistem LoRa). O să arunc o privire la netdata, arată bine. Problema este că persoanele responsabile pentru acest server pun fiecare server pe aceeași instanță, în loc să-l răspândească. Probabil a funcționat la început, dar pe măsură ce sistemul crește, acest lucru nu este sustenabil. Mulțumesc tuturor pentru ideile bune!

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.