Jaki jest koszt wydajności środowiska wykonawczego kontenera Docker?

511

Chciałbym kompleksowo zrozumieć koszt wydajności w czasie wykonywania kontenera Docker. Znalazłem odniesienia do anegdotycznego bycia w sieci o ~ 100µs wolniej .

Znalazłem również odniesienia do kosztów w czasie wykonywania, które są „znikome” i „bliskie zeru”, ale chciałbym wiedzieć dokładniej, jakie są te koszty. Idealnie chciałbym wiedzieć, co abstrakuje Docker kosztem wydajności i rzeczy, które są abstrakcyjne bez kosztu wydajności. Sieć, procesor, pamięć itp.

Ponadto, jeśli istnieją koszty abstrakcji, czy istnieją sposoby na obejście kosztów abstrakcji. Na przykład być może uda mi się zamontować dysk bezpośrednio vs. wirtualnie w Docker.

performance docker

— Luke Hoersten
źródło

możliwy duplikat Czy istnieje wzór do obliczania narzutu kontenera Docker?

— Golo Roden

@GoloRoden to pytanie jest podobne, ale nie dokładnie takie samo. Szukam kosztów opóźnienia z powodów takich jak „sieć przechodzi przez dodatkową warstwę”, podczas gdy zaakceptowana odpowiedź na to pytanie dotyczy bardziej pomiaru kosztów kontenera + aplikacji.

— Luke Hoersten

OK, zgadza się. Wycofałem mój głos.

— Golo Roden

Cieszę się, że to opublikowałeś. To pytanie nie pojawiło się podczas moich poszukiwań. Artykuł o pomiarach / pomiarach jest bardzo przydatny: blog.docker.io/2013/10/gathering-lxc-docker-containers-metrics

— Luke Hoersten

To dobra sesja zatytułowana „Linux Containers - NextGen Virtualization for Cloud”, która przedstawia wskaźniki wydajności poprzez porównanie dokera, maszyny wirtualnej KVM i gołego metalu: youtube.com/watch?v=a4oOAVhNLjU

— shawmzhu

Odpowiedzi:

449

Doskonały artykuł badawczy IBM z 2014 r. „ Zaktualizowane porównanie wydajności maszyn wirtualnych i kontenerów Linux ” autorstwa Feltera i in. zapewnia porównanie między czystym metalem, KVM i pojemnikami Docker. Ogólny wynik jest następujący: Docker jest prawie identyczny z wydajnością natywną i szybszy niż KVM w każdej kategorii.

Wyjątkiem jest NAT Dockera - jeśli używasz mapowania portów (np. docker run -p 8080:8080), Możesz spodziewać się niewielkiego trafienia z opóźnieniem, jak pokazano poniżej. Możesz jednak teraz użyć stosu sieci hosta (np. docker run --net=host) Podczas uruchamiania kontenera Docker, który będzie działał identycznie jak kolumna Native (jak pokazano w wynikach opóźnienia Redis poniżej).

Narzut Docker NAT

Przeprowadzili także testy opóźnień dla kilku konkretnych usług, takich jak Redis. Widać, że powyżej 20 wątków klienta najwyższe opóźnienie przypada na NAT Docker, następnie KVM, a następnie szorstki związek między hostem / natywnym Docker.

Docker Redis Opóźnienie ogólne

Tylko dlatego, że jest to bardzo przydatny papier, oto kilka innych liczb. Pobierz go, aby uzyskać pełny dostęp.

Spojrzenie na dyskowe operacje we / wy:

Docker vs. KVM vs. Natywna wydajność we / wy

Teraz patrząc na obciążenie procesora:

Obciążenie procesora stacji dokującej

Teraz kilka przykładów pamięci (przeczytaj artykuł, szczegóły mogą być bardzo trudne):

Porównanie pamięci dokerów

— Hamy
źródło

Jeśli chodzi o liczby linpatów podane w artykule ... szczerze mówiąc, trudno mi w to uwierzyć (nie dlatego, że nie wierzę, że są tym, co emitował linpack, ale nie wierzę, że test naprawdę mierzył jedynie wydajność zmiennoprzecinkową, ponieważ wykonano). Główny narzut związany z KVM dotyczy komponentów emulacji przestrzeni użytkownika (które dotyczą tylko sprzętu bez procesora ); wokół stronicowania pamięci jest znaczny narzut ... ale surowy zmiennoprzecinkowy? Chciałbym spojrzeć na to, co się tam właściwie dzieje - być może nadmierne zmiany kontekstu.

— Charles Duffy,

Korekta bieżącej składni interfejsu Docker CLI: --net=host(dwa myślniki) i -p 8080:8080(małe litery „p”) dla NAT.

— bk0,

Cytowany artykuł IBM wydaje się zbyt skoncentrowany na sieciowym We / Wy. Nigdy nie dotyczy przełączników kontekstu. Przyjrzeliśmy się LXC i musieliśmy szybko go porzucić ze względu na zwiększoną liczbę nieobowiązkowych przełączników kontekstu, powodujących pogorszenie przetwarzania aplikacji.

— Eric

Jestem również ciekawy operacji na systemie plików - na przykład wyszukiwania katalogów są miejscem, w którym spodziewałbym się zobaczyć narzut; odczyty, zapisy i poszukiwania na poziomie bloku (na których mocno koncentrują się podane wykresy) nie są .

— Charles Duffy

Uwielbiam wykresy o tym samym odcieniu. Tak łatwo to odróżnić

— Viktor Joras

104

Docker nie jest wirtualizacją jako taką - zamiast tego jest abstrakcją nad obsługą jądra dla różnych przestrzeni nazw procesów, przestrzeni nazw urządzeń itp .; jedna przestrzeń nazw nie jest z natury droższa ani nieefektywna od innej, więc to, co faktycznie powoduje, że Docker ma wpływ na wydajność, zależy od tego, co faktycznie znajduje się w tych przestrzeniach nazw.

Wybory Dockera pod względem konfiguracji przestrzeni nazw dla jego kontenerów wiążą się z kosztami, ale wszystkie te koszty są bezpośrednio związane z korzyściami - możesz je zrezygnować, ale robiąc to, rezygnujesz również z powiązanych korzyści:

Warstwowe systemy plików są drogie - dokładnie te same koszty są różne dla każdego z nich (a Docker obsługuje wiele backendów), a także z twoimi wzorcami użytkowania (łączenie wielu dużych katalogów lub łączenie bardzo głębokiego zestawu systemów plików będzie szczególnie drogie), ale one nie są wolne. Z drugiej strony duża część funkcjonalności Dockera - możliwość budowania gości z innych gości w sposób umożliwiający kopiowanie na piśmie i uzyskiwanie ukrytych korzyści z przechowywania - wiąże się z opłaceniem tego kosztu.
DNAT staje się drogi na dużą skalę - ale daje Ci możliwość konfigurowania sieci gościa niezależnie od hosta i posiada wygodny interfejs do przesyłania tylko żądanych portów między nimi. Możesz zastąpić to mostem do interfejsu fizycznego, ale znowu stracisz korzyść.
Możliwość uruchomienia każdego stosu oprogramowania z zainstalowanymi zależnościami w najwygodniejszy sposób - niezależnie od dystrybucji hosta, biblioteki libc i innych wersji bibliotek - jest wielką zaletą, ale wymaga ładowania bibliotek współdzielonych więcej niż raz (gdy ich wersje różnią się) ma oczekiwany koszt.

I tak dalej. Jak bardzo te koszty wpływają na Ciebie w twoim środowisku - z twoimi wzorcami dostępu do sieci, ograniczeniami pamięci itp. - jest elementem, na który trudno jest udzielić ogólnej odpowiedzi.

— Charles Duffy
źródło

To dobra odpowiedź, ale szukam bardziej szczegółowych liczb i testów porównawczych. Jestem zaznajomiony z kosztami grup, ale Docker to coś więcej, jak zauważyłeś. Wielkie dzięki za odpowiedź.

— Luke Hoersten

Pewnie. Chodzi mi o to, że wszelkie uogólnione testy porównawcze będą miały bardzo ograniczone zastosowanie do każdej konkretnej aplikacji - ale to nie znaczy, że nie zgadzam się z ludźmi, którzy próbują je dostarczyć, ale po prostu, że należy je zabrać ze sobą dużą łyżką soli.

— Charles Duffy,

W ten sposób można powiedzieć, że KVM „nie jest wirtualizacją, jest po prostu abstrakcją na podstawie wywołań technologii wirtualnej x86”.

— Vad,

@Vad, istnieje konsensus, sięgający dziesięcioleci (do wczesnych implementacji sprzętowych IBM innych niż x86!), Że zapewnianie abstrakcji bezpośrednio na warstwie sprzętowej jest jednoznacznie wirtualizacją. Konsensus w sprawie terminologii dotyczącej przestrzeni nazw na poziomie jądra jest znacznie bardziej rozdrobniony - każdy z nas mógłby wskazać źródła faworyzujące nasze indywidualne poglądy - ale szczerze mówiąc, istnieją użyteczne techniczne rozróżnienia (dotyczące zarówno charakterystyki bezpieczeństwa, jak i wydajności), które przejście do jednego terminu byłoby niejasne , więc utrzymuję swoją pozycję do momentu osiągnięcia konsensusu branżowego.

— Charles Duffy,

@LukeHoersten, ... prawda, to nie grupy kapitałowe mają znaczny koszt, to bardziej zawartość sieci i przestrzeni nazw systemu plików. Ale ile kosztują te koszty, zależy prawie całkowicie od konfiguracji Dockera - z jakich konkretnych backendów korzystasz. Na przykład mostkowanie jest znacznie, znacznie tańsze niż domyślny NAT Dockera; a narzuty wydajności różnych systemów plików również bardzo się różnią (w niektórych przypadkach wielkość narzutu zależy od wzorców użytkowania; warianty nakładek mogą być znacznie droższe przy dużych katalogach modyfikowanych przez wiele warstw f / e).

— Charles Duffy

Oto kilka testów porównawczych w Docker based memcached serverporównaniu z host native memcached serverużyciem narzędzia do testów porównawczych Twemperf https://github.com/twitter/ przedstawperf z 5000 połączeń i szybkością połączenia 20k

Narzut czasu połączenia dla memcached na podstawie dokera wydaje się zgadzać z powyższym oficjalnym dokumentem z prędkością około dwa razy natywną.

Twemperf Docker Memcached

Connection rate: 9817.9 conn/s
Connection time [ms]: avg 341.1 min 73.7 max 396.2 stddev 52.11
Connect time [ms]: avg 55.0 min 1.1 max 103.1 stddev 28.14
Request rate: 83942.7 req/s (0.0 ms/req)
Request size [B]: avg 129.0 min 129.0 max 129.0 stddev 0.00
Response rate: 83942.7 rsp/s (0.0 ms/rsp)
Response size [B]: avg 8.0 min 8.0 max 8.0 stddev 0.00
Response time [ms]: avg 28.6 min 1.2 max 65.0 stddev 0.01
Response time [ms]: p25 24.0 p50 27.0 p75 29.0
Response time [ms]: p95 58.0 p99 62.0 p999 65.0

Twemperf Centmin Mod Memcached

Connection rate: 11419.3 conn/s
Connection time [ms]: avg 200.5 min 0.6 max 263.2 stddev 73.85
Connect time [ms]: avg 26.2 min 0.0 max 53.5 stddev 14.59
Request rate: 114192.6 req/s (0.0 ms/req)
Request size [B]: avg 129.0 min 129.0 max 129.0 stddev 0.00
Response rate: 114192.6 rsp/s (0.0 ms/rsp)
Response size [B]: avg 8.0 min 8.0 max 8.0 stddev 0.00
Response time [ms]: avg 17.4 min 0.0 max 28.8 stddev 0.01
Response time [ms]: p25 12.0 p50 20.0 p75 23.0
Response time [ms]: p95 28.0 p99 28.0 p999 29.0

Oto bencmark za pomocą narzędzia do testów memtier

memtier_benchmark docker Memcached

4         Threads
50        Connections per thread
10000     Requests per thread
Type        Ops/sec     Hits/sec   Misses/sec      Latency       KB/sec
------------------------------------------------------------------------
Sets       16821.99          ---          ---      1.12600      2271.79
Gets      168035.07    159636.00      8399.07      1.12000     23884.00
Totals    184857.06    159636.00      8399.07      1.12100     26155.79

memtier_benchmark Centmin Mod Memcached

4         Threads
50        Connections per thread
10000     Requests per thread
Type        Ops/sec     Hits/sec   Misses/sec      Latency       KB/sec
------------------------------------------------------------------------
Sets       28468.13          ---          ---      0.62300      3844.59
Gets      284368.51    266547.14     17821.36      0.62200     39964.31
Totals    312836.64    266547.14     17821.36      0.62200     43808.90

— p4guru
źródło

Porównują dwie różne wersje memcached, a także jedną z nich w dokerze, inną poza dokerem, prawda?

— san

Czy te wyniki dotyczą sieci hosta lub sieci mostkowej w oknie dokowanym?

— alias Humum

Przy tak dużych standardach pomiary te nie pokazują żadnych reprezentatywnych danychavg 200.5 min 0.6 max 263.2 stddev 73.85

— Sergey Zhukov