Docker konteynerinin çalışma zamanı performans maliyeti nedir?


512

Docker konteynerinin çalışma zamanı performans maliyetini kapsamlı bir şekilde anlamak istiyorum. Anekdotal ağ ~ 100µs yavaş olmak için referanslar buldum .

Ayrıca çalışma zamanı maliyet "ihmal edilebilir" ve "sıfıra yakın" referansları buldum ama bu maliyetlerin ne olduğunu daha kesin bilmek istiyorum. İdeal olarak Docker'ın bir performans maliyetiyle neyi soyutladığını ve performans maliyeti olmadan soyutlanan şeyleri bilmek istiyorum. Ağ, CPU, bellek vb.

Ayrıca, soyutlama maliyetleri varsa, soyutlama maliyetini aşmanın yolları vardır. Örneğin, bir diski doğrudan Docker'a veya doğrudan Docker'a bağlayabilirim.



1
@GoloRoden bu soru benzer ama tam olarak aynı değil. "Ağ ekstra bir katmandan geçiriliyor" gibi nedenlerle gecikme maliyetleri arıyorum, bu sorunun kabul edilen cevabı konteyner + app maliyetlerini ölçme hakkında daha fazladır.
Luke Hoersten

1
Tamam, doğru. Yakın oyumu geri çektim.
Golo Roden

8
Yine de gönderdiğine sevindim. Bu soru aramamda ortaya çıkmadı. Ölçüm / metrikler makalesi çok kullanışlıdır: blog.docker.io/2013/10/gathering-lxc-docker-containers-metrics
Luke Hoersten

1
Bu, docker, KVM VM ve çıplak metali karşılaştırarak performans metriklerini anlatan "Linux Kapsayıcılar - NextGen Sanallaştırma için Bulut" başlıklı iyi bir oturum: youtube.com/watch?v=a4oOAVhNLjU
shawmzhu 22:14

Yanıtlar:


449

Felter ve ark.'nın 2014 IBM araştırma makalesi “ Sanal Makinelerin ve Linux Kaplarının Güncellenmiş Performans Karşılaştırması ”. çıplak metal, KVM ve Docker konteynerleri arasında bir karşılaştırma sağlar. Genel sonuç şudur: Docker yerel performansla neredeyse aynıdır ve her kategoride KVM'den daha hızlıdır.

Bunun istisnası Docker'ın NAT'sıdır - bağlantı noktası eşlemesi (örneğin, docker run -p 8080:8080) kullanıyorsanız, aşağıda gösterildiği gibi gecikme sırasında küçük bir isabet bekleyebilirsiniz. Bununla birlikte, artık docker run --net=hostYerel sütuna benzer performans gösterecek bir Docker kapsayıcısını başlatırken ana bilgisayar ağ yığınını (örn. ) Kullanabilirsiniz (Redis gecikme sonuçlarında aşağıda gösterildiği gibi).

Docker NAT yükü

Ayrıca, Redis gibi birkaç özel hizmet üzerinde gecikme testleri gerçekleştirdiler. 20'den fazla istemci iş parçacığının, en yüksek gecikme yükünün Docker NAT, ardından KVM, sonra Docker ana bilgisayarı / yerli arasında kaba bir bağ olduğunu görebilirsiniz.

Docker Redis Latency Tepegöz

Bunun gerçekten faydalı bir kağıt olması nedeniyle, başka rakamlar da var. Lütfen tam erişim için indirin.

Disk G / Ç'ye göz atmak:

Docker ve KVM ve Yerel I / O Performansı

Şimdi CPU yüküne bakalım:

Docker CPU Tepegöz

Şimdi bazı bellek örnekleri (ayrıntılar için makaleyi okuyun, bellek çok zor olabilir):

Docker Bellek Karşılaştırması


20
Gazetede verilen linpack numaralarına gelince ... açıkçası, inanmaları zor buluyorum (linpack'in yaydığı şey olduğuna inanmıyorum, ancak testin kayan nokta performansından başka hiçbir şeyi ölçmediğine inanmıyorum. yapılır). KVM'nin ana yükü, kullanıcı alanı donanım öykünme bileşenlerinde (yalnızca CPU olmayan donanımlar için geçerlidir ); bellek disk belleği etrafında önemli bir yük var ... ama ham kayan nokta? Aslında neler olup bittiğine bakmak istiyorum - belki de aşırı bağlam anahtarları.
Charles Duffy

2
Geçerli Docker CLI sözdizimi için düzeltme: NAT için --net=host(iki tire) ve -p 8080:8080(küçük harf 'p').
bk0

6
Alıntı yapılan IBM belgesi ağ IO'suna çok odaklanmış gibi görünüyor. Hiçbir zaman bağlam anahtarlarını ele almaz. LXC'ye baktık ve artan gönüllü olmayan işlem anahtarları nedeniyle uygulama uygulamalarının bozulmasına yol açan hızlı bir şekilde terk etmek zorunda kaldık.
Eric

3
Ben de dosya sistemi işlemleri merak ediyorum - örneğin, dizin aramaları, ek yükü beklediğiniz bir yer; Blok seviyesinden, yazma okur ve (verilen grafikler ağır odaklanmak olan) arar değildir .
Charles Duffy

12
Aynı gölge rengine sahip grafikleri seviyorum. Ayırt etmek çok kolay
Viktor Joras

104

Docker bu şekilde sanallaştırma değildir - bunun yerine, çekirdeğin farklı işlem ad alanları, aygıt ad alanları vb. Desteğinin üstünde bir soyutlamadır; aslında ne Docker bir performans etkisi aslında ne meselesidir var kılan bu yüzden bir ad, doğal olarak daha pahalı ya da başka daha verimsiz değil de bu ad.


Docker'ın konteynırları için ad alanlarını nasıl yapılandıracağına ilişkin seçimleri maliyetlidir, ancak bu maliyetlerin tümü doğrudan avantajlarla ilişkilidir - bunları bırakabilirsiniz, ancak bunu yaparken ilgili avantajdan da vazgeçersiniz:

  • Katmanlı dosya sistemleri pahalıdır - maliyetlerin her biri için tam olarak ne olduğu (ve Docker birden fazla arka ucu destekliyor) ve kullanım kalıplarınızla (birden çok büyük dizini birleştirmek veya çok derin bir dosya sistemini birleştirmek özellikle pahalı olacaktır), ancak bunlar özgür değilim. Öte yandan, Docker'in işlevselliği - konukları yazma üzerine kopyalayarak diğer konuklardan kurtarabilme ve depolama avantajlarını aynı şekilde örtük hale getirme - bu maliyeti ödemeye devam edin.
  • DNAT ölçeğe göre pahalı hale gelir - ancak misafirinizin ağını ana makinenizden bağımsız olarak yapılandırabilme ve yalnızca aralarında istediğiniz bağlantı noktalarını yönlendirmek için kullanışlı bir arayüze sahip olma avantajı sağlar. Bunu fiziksel bir arayüze bir köprü ile değiştirebilirsiniz, ancak yine de faydasını kaybedebilirsiniz.
  • Her yazılım yığınını, ana bilgisayarın dağıtım, libc ve diğer kütüphane sürümlerinden bağımsız olarak, en uygun şekilde yüklenen bağımlılıklarıyla çalıştırabilmek büyük bir avantajdır, ancak paylaşılan kütüphaneleri birden fazla kez yüklemeleri gerekir (sürümleri farklı) beklediğiniz maliyete sahiptir.

Ve böylece. Bu maliyetlerin ortamınızda sizi ne kadar etkilediği (ağ erişim kalıplarınız, bellek kısıtlamalarınız vb.), Genel bir yanıt vermenin zor olduğu bir öğedir.


2
Bu iyi bir cevap ama daha spesifik rakamlar ve kıyaslamalar arıyorum. Grupların maliyetine aşinayım, ancak Docker, işaret ettiğiniz gibi bundan daha fazlası. Cevabınız için çok teşekkürler.
Luke Hoersten

6
Elbette. Demek istediğim, bulduğunuz herhangi bir genel kriter, herhangi bir belirli uygulama için çok sınırlı bir uygulanabilirliğe sahip olacak - ancak bu, onları sağlamaya çalışan insanlarla aynı fikirde olmadığımı değil, sadece bir yığın çorba kaşığı tuzla alınmaları gerektiği anlamına geliyor.
Charles Duffy

1
Bu şekilde KVM'nin "bir sanallaştırma değil, sadece x86 sanal teknoloji çağrılarının üstünde bir soyutlama olduğunu" söyleyebilirsiniz.
Vad

10
@Vad, onlarca yıl geriye (IBM'in x86 dışındaki erken donanım uygulamalarına!) Doğrudan donanım katmanında soyutlama sağlamanın net bir şekilde sanallaştırma olduğuna dair bir fikir birliği anlaşması var. Çekirdek düzeyinde ad alanı etrafında terminoloji konusunda fikir birliği çok daha parçalı - her birimiz bireysel görüşlerimizi tercih eden kaynaklara işaret edebiliriz - ancak açıkçası, tek bir terime geçmenin belirsiz olacağı yararlı teknik ayrımlar (hem güvenlik hem de performans özellikleri etrafında) vardır. Bu yüzden, aksine endüstri konsensüsüne ulaşılıncaya kadar pozisyonumu koruyorum.
Charles Duffy

@LukeHoersten, ... doğru, önemli bir maliyeti olan gruplar değil, ağın ve dosya sistemi ad alanlarının içeriği çok daha fazla. Ancak bu maliyetlerin ne kadarı neredeyse tamamen Docker'ın nasıl yapılandırıldığına bağlıdır - hangi belirli arka uçları kullanıyorsunuz. Köprüleme Docker'ın varsayılan NAT değerinden çok, çok daha ucuzdur; ve çeşitli dosya sistemi arka uçlarının performans yükü de çılgınca değişir (ve bazı durumlarda genel yük miktarı kullanım şekillerine bağlıdır; bindirme varyantları, birden çok katman f / e aracılığıyla değiştirilen büyük dizinlerle çok daha pahalı olabilir).
Charles Duffy

20

Burada biraz daha var kriterler için Docker based memcached serverkarşı host native memcached serverTwemperf kriter aracını kullanarak https://github.com/twitter/twemperf 5000 bağlantıları ve 20k bağlantı hızıyla

Docker tabanlı memcached için bağlantı zamanı yükü, yukarıdaki teknik incelemeye yaklaşık iki kat doğal hızda katılıyor gibi görünüyor.

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

İşte memtier benchmark aracını kullanarak bencmarks

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

1
İki farklı memcached yapısını karşılaştırıyorlar ve bunlardan biri liman işçisinde, liman işçisinin dışında, öyle değil mi?
san

4
Bu sonuçlar ana bilgisayar ağında mı yoksa docker'da köprü ağında mı?
akaİnsan

13
Böyle büyük stddevs'lerle bu ölçümlerde temsili herhangi bir veri gösterilmezavg 200.5 min 0.6 max 263.2 stddev 73.85
Sergey Zhukov
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.