도커 컨테이너의 런타임 성능 비용은 얼마입니까?

도커 컨테이너의 런타임 성능 비용은 얼마입니까?

도커 컨테이너의 런타임 성능 비용을 종합적으로 파악하고 싶습니다.저는 네트워킹에 대한 언급이 일화적으로 100초 이상 느리다는 것을 발견했습니다.

또한 런타임 비용이 "무시"하고 "제로에 가깝다"는 언급을 발견했지만, 그 비용이 무엇인지 더 정확하게 알고 싶습니다.이상적으로 도커가 성능 비용으로 추상화하는 것과 성능 비용 없이 추상화되는 것을 알고 싶습니다.네트워킹, CPU, 메모리 등.

또한, 추상화 비용이 있다면, 추상화 비용을 피할 수 있는 방법이 있습니까?예를 들어 가상으로 Docker에 디스크를 직접 마운트할 수 있습니다.

Felter 등의 2014년 IBM 연구 논문 "가상 머신과 리눅스 컨테이너의 업데이트된 성능 비교"에서는 베어메탈, KVM 및 도커 컨테이너를 비교합니다.일반적인 결과는 다음과 같습니다. 도커는 기본 성능과 거의 동일하며 모든 범주에서 KVM보다 빠릅니다.

매핑 포트 매핑)을 입니다.docker run -p 8080:8080), 그러면 아래와 같이 대기 시간에 약간의 히트를 예상할 수 있습니다. 이제 스택 그러이호네스예사수있용습다니할을택크)을 할 수 docker run --net=hostDocker 컨테이너를 시작할 때 Native 열과 동일한 성능을 발휘합니다(Redis 대기 시간 결과에 표시된 바와 같이 아래쪽).

또한 Redis와 같은 일부 특정 서비스에 대해서도 대기 시간 테스트를 실행했습니다.20개 이상의 클라이언트 스레드에서 가장 높은 지연 시간 오버헤드가 Docker NAT, 다음으로 KVM, 다음으로 Docker 호스트/네이티브 간의 대략적인 연결로 이어지는 것을 확인할 수 있습니다.

정말 유용한 논문이기 때문에, 여기 다른 수치들이 있습니다.전체 액세스를 위해 다운로드하십시오.

Disk I/O 확인:

이제 CPU 오버헤드를 살펴봅니다.

이제 메모리의 몇 가지 예를 보겠습니다(자세한 내용은 문서를 참조하십시오. 메모리가 특히 까다로울 수 있습니다).

도커는 가상화가 아닙니다. 즉, 다양한 프로세스 네임스페이스, 장치 네임스페이스 등에 대한 커널의 지원과 더불어 추상화입니다. 한 네임스페이스가 본질적으로 다른 네임스페이스보다 더 비싸거나 비효율적인 것은 아니므로 도커가 실제로 성능에 영향을 미치는 것은 이러한 네임스페이스에 무엇이 있는지에 대한 문제입니다.

---

컨테이너의 네임스페이스를 구성하는 방법에 대한 Docker의 선택은 비용이 들지만, 이러한 비용은 모두 이점과 직접적으로 관련되어 있습니다. 이를 포기할 수도 있지만, 그렇게 함으로써 관련 이점도 포기할 수 있습니다.

• 계층화된 파일 시스템은 비용이 많이 듭니다. 비용은 각 시스템에 따라 정확히 다릅니다(Docker는 여러 백엔드를 지원합니다). 사용 패턴에 따라 다릅니다(여러 개의 큰 디렉토리를 병합하거나 매우 깊은 파일 시스템 집합을 병합하는 경우 특히 비용이 많이 들 것입니다). 하지만 무료는 아닙니다.반면에 Docker의 기능 중 상당 부분은 Copy-on-Write 방식으로 다른 게스트로부터 게스트를 구축할 수 있고 스토리지 이점을 동시에 얻을 수 있습니다. 이 비용을 지불해야 합니다.
• DNAT은 규모 면에서 비용이 많이 들지만 호스트와 독립적으로 게스트 네트워킹을 구성할 수 있고 게스트 간에 원하는 포트만 전달할 수 있는 편리한 인터페이스를 제공합니다.이를 물리적 인터페이스에 대한 브리지로 대체할 수 있지만, 다시 말하지만 이점을 잃게 됩니다.
• 호스트의 디스트리뷰터, libc 및 기타 라이브러리 버전과 관계없이 가장 편리한 방식으로 각 소프트웨어 스택을 설치하여 실행할 수 있다는 것은 큰 이점이 있지만, (버전이 다를 때) 공유 라이브러리를 두 번 이상 로드해야 하는 경우 예상되는 비용이 듭니다.

등등.네트워크 액세스 패턴, 메모리 제약 등과 같은 이러한 비용이 실제로 사용자 환경에 얼마나 영향을 미치는지는 일반적인 답변을 제공하기 어려운 항목입니다.

다음은 에 대한 몇 가지 벤치마크입니다.Docker based memcached server 대host native memcached serverTwemperf 벤치마크 툴 https://github.com/twitter/twemperf 을 사용하여 5000개의 연결과 20,000개의 연결 속도를 제공합니다.

도커 기반 memcached에 대한 연결 시간 오버헤드는 기본 속도의 약 두 배로 위의 백서와 일치하는 것으로 보입니다.

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

다음은 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

런타임 라이브러리 비교

런타임 라이브러리와 관련하여 컨테이너의 런타임 성능 비용에 대한 질문에 접근하고자 합니다.

속도: 무슬림 vs. glibc

Appline Linux 컨테이너에서 런타임 라이브러리는 glibc 대신 Musl에 의해 제공되며 아래 링크에 따르면 둘 사이에 성능 차이가 있을 수 있습니다.

https://www.etalabs.net/compare_libcs.html

저는 이 주제를 연구하면서 다양한 의견을 읽었는데, 무슬림은 작고 훨씬 더 현대적이기 때문에 glibc보다 어느 정도 더 큰 보안을 제공합니다.그러나 이러한 보기를 지원하는 데이터를 찾을 수 없습니다.

호환성.

그러나 Musl이 glibc와 실질적으로 다르기 때문에 Musl이 더 빠르고 더 안전하다고 하더라도 호환성 문제가 발생할 수 있습니다.하지만 다음을 사용하여 도커 이미지를 만드는 경우apk내 패키지를 끌어오기 위해, 물론 기능 문제는 없습니다.

결론

성능이 중요한 경우 Glibc를 사용하는 디스트리뷰터를 사용하여 (2)개의 Alpine Linux와 Musl을 사용하는 다른 Alpine Linux 컨테이너를 잘라내고 이를 벤치마킹합니다.그리고 물론 여러분의 결과를 댓글에 올리세요.!!

언급URL : https://stackoverflow.com/questions/21889053/what-is-the-runtime-performance-cost-of-a-docker-container