Puncte:0

Execuția Docker mai lentă pe gazda EC2

drapel hk

Am creat recent o imagine docker pentru a rula instrumentul Terraspace pentru a executa CI/CD-ul nostru în conductele GitLab. Recipientul folosește rubin:3.0.2-alpin pentru că este în amonte, pentru referință.

Problema cu care ne confruntăm este că este extrem de lent atunci când este executat pe EC2 (m5.large), iată câteva momente care includ rularea instrumentului în interiorul imaginii docker și nativ pe gazdă.Timingurile docker sunt efectuate în interiorul imaginii după ce aceasta a fost deja descărcată.

EC2 Docker EC2 Docker local Local
5m33.403s reale 0m44.799s reale real 1m40.842s 0m39.626s reale
utilizator 0m11.150s utilizator 0m26.531s utilizator 0m24.736s utilizator 0m10.913s
sys 0m1.437s sys 0m3.276s sys 0m13.846s sys 0m4.580

Execuția mai lentă în interiorul docker este valabilă și pentru imaginea standard de terraspace boltops/terraspace.

Nu pare a fi o problemă de utilizare a resurselor, deoarece există o mulțime de resurse rămase pe gazdă în timpul execuției

CONTAINER ID NUME CPU % MEM UTILIZARE / LIMIT MEM % NET I/O BLOC I/O PIDS
9b05765250b8 quirky_spence 0,54% 1,21GiB / 7,583GiB 15,95% 300MB / 3,43MB 0B / 1,08MB 3

Iată informațiile despre mașina docker:

lient:
 Context: implicit
 Modul de depanare: fals

Server:
 Recipiente: 4
  Alergare: 0
  Întrerupt: 0
  Oprit: 4
 Imagini: 3
 Versiunea serverului: 20.10.4
 Driver de stocare: overlay2
  Sistem de fișiere de rezervă: xfs
  Suporta d_type: true
  Native Overlay Diff: adevărat
 Driver de înregistrare: json-file
 Driver Cgroup: cgroupfs
 Versiunea Cgroup: 1
 Pluginuri:
  Volum: local
  Rețea: bridge host ipvlan macvlan null overlay
  Jurnal: awslogs fluentd gcplogs gelf journald json-file logentries locale splunk syslog
 Roi: inactiv
 Durate de execuție: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Timp de rulare implicit: runc
 Init Binary: docker-init
 versiune containerd: d71fcd7d8303cbf684402823e425e9dd2e99285d
 versiune runc: %runc_commit
 versiune init: de40ad0
 Opțiuni de securitate:
  seccomp
   Profil: implicit
 Versiunea Kernel: 4.14.238-182.422.amzn2.x86_64
 Sistem de operare: Amazon Linux 2
 OSType: Linux
 Arhitectură: x86_64
 CPU: 2
 Memorie totală: 7.583 GiB
 Nume: ip-10-0-4-227
 ID: FUYW:PCXQ:5ZFW:4SMP:YIG4:RNBH:HCMH:6R53:NHS2:HTJO:VAKM:5QFB
 Docker Root Dir: /var/lib/docker
 Modul de depanare: fals
 Registrul: https://index.docker.io/v1/
 Etichete:
 Experimental: fals
 Registre nesigure:
  127.0.0.0/8
 Oglinzi de registru:
  https://docker-proxy/
 Restaurare live activată: fals

Orice ajutor ar fi apreciat în acest sens.

Michael Hampton avatar
drapel cz
Verificați DNS-ul dvs.
Sam Smart avatar
drapel hk
Tocmai verificat, DNS este în regulă. Nu se rezolvă probleme din interiorul containerului.
Michael Hampton avatar
drapel cz
Interesant. Ei bine, cifrele spun că petrece mult timp în container _fără nimic_, adică așteptând ceva, în care acest timp nu este cu adevărat consumat atunci când rulează în afara containerului. De obicei, aceasta este o problemă DNS, deși ar putea fi doar o problemă generală de conectivitate sau cu totul altceva pe care aplicația își petrece timpul așteptând.
rvs avatar
drapel vn
rvs
I/O ar fi următoarea mea presupunere.

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.