Puncte:0

Containerele pot fi plasate pe gazda EC2 în mod supraîncărcat în AWS ECS

drapel ua

Am o instanță cu mai multe aplicații Tomcat și borcane independente care rulează. Dacă mașina are 2vcpu și 8 GB RAM, aplicațiile individuale pot folosi resursele la cerere (pe baza valorilor Xms și Xmx setate pentru Tomcat și pentru borcanele individuale). ECS nu este în imagine în acest moment.

Acum voi muta aplicația în containere pe instanțe EC2 (nu fargate). Este posibil să existe definiții de sarcini în care să specific procesorul și memoria care însumează a fi mai mari decât CPU-ul sau memoria RAM reală a gazdei EC2?

Pentru că nu mă aștept ca toate aplicațiile să utilizeze 100% din memoria alocată acesteia în timpul creării definiției sarcinii. Ar funcționa să am o gazdă ECS cu 4vcpus și plasez 10 sarcini pe toate cu 4vcpus specificat în definiția sarcinii? Știu că sarcinile nu vor utiliza 4vcpu, dar vreau ca, dacă vreuna dintre sarcini trebuie să fie utilizată, să nu fie restricționată pentru a utiliza capacitatea maximă a gazdei

Știu că ECS are capacități de scalare pe care intenționez să le folosesc.Dar îmi propun să mă asigur că nu supraalimentez numărul de gazde EC2 pe care le folosesc pentru ECS

Puncte:0
drapel nl

Răspunsul scurt este că îl poți realiza, dar cu o nuanță. Dacă configurați dimensiunea definiției sarcinii, nu veți putea supracomita resursele CPU/memorie. Cu toate acestea, dacă implementați în EC2, puteți omite dimensiunea sarcinii în definiția sarcinii și se presupune că toate sarcinile ar putea accesa toată capacitatea gazdă. Puteți ajusta apoi resursele CPU/memorie (garanție/plafon etc.) la nivel de containere individuale. Acest lucru vă va permite să vă supraangajați.

Răspunsul mai lung este Aici.

Kohini avatar
drapel ua
Ar trebui să setez valorile Xms și Xmx în imaginea Tomcat? Îmi imaginez că dacă nu setez în imagine, deși resursele gazdă ec2 sunt disponibile pentru container, parametrii impliciti ai java vor intra în joc pentru a determina câtă memorie poate folosi aplicația implementată în tomcat. Mulțumiri!
mreferre avatar
drapel nl
Aceasta depinde de versiunea Java specifică utilizată. Versiunea anterioară a Java nu le va păsa de containere/cgroup-uri și ar presupune doar că TOATE resursele gazdă pe care le văd (pentru că pot vedea TOATE resursele întotdeauna) sunt disponibile pentru ei. Versiunile ulterioare de Java sunt suficient de inteligente pentru a realiza că trăiesc în limitele virtuale ale cgroups și sunt conștiente de construcția containerelor (deci știu cât de mult le-a fost dat). Setarea de către IMO a acestor parametri în cadrul aplicației nu este niciodată o idee rea, indiferent. PS există o notă pe blog despre asta.
Kohini avatar
drapel ua
Există o linie în blog `dacă stabilești doar limita tare, care reprezintă atât rezervarea, cât și plafonul` care pare să nu aibă sens. Dacă am setat doar limita strictă de 2 GB (dar nu limită soft) de ce ar fi și valoarea rezervată pentru container? Mi-aș imagina că în absența limitei soft nu există memorie rezervată, doar memoria de care are nevoie containerul este luată de la gazdă, iar limita de 2 GB este limita strictă.
mreferre avatar
drapel nl
Așa a fost implementat. Cred că se datorează faptului că atunci când nu setați o dimensiune a sarcinii, sistemul trebuie să cunoască cantitatea de memorie rezervată și, dacă nu este setată, limita este luată drept rezervare. Dacă doriți ca limita să fie diferită, atunci rezervarea trebuie să le setați în mod explicit pe ambele.

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.