Какова стоимость производительности во время выполнения контейнера Docker?

512

Я хотел бы в полной мере понять стоимость производительности во время выполнения контейнера Docker. Я обнаружил, что ссылки на сетевое взаимодействие были на ~ 100 мкс медленнее .

Я также нашел ссылки на то, что затраты времени выполнения «незначительны» и «близки к нулю», но я хотел бы знать более точно, каковы эти затраты. В идеале я хотел бы знать, что Docker абстрагирует со стоимостью производительности и вещами, которые абстрагируются без затрат производительности. Сеть, процессор, память и т. Д.

Кроме того, если есть затраты на абстракцию, есть ли способы обойти стоимость абстракции. Например, возможно, я могу смонтировать диск напрямую или практически в Docker.

performance docker

— Люк Хёрстен
источник

Возможный дубликат Есть ли формула для расчета накладных расходов контейнера Docker?

— Голо Роден

@GoloRoden этот вопрос похож, но не совсем то же самое. Я ищу затраты на задержку по таким причинам, как «сеть проходит через дополнительный уровень», в то время как принятый ответ на этот вопрос больше касается измерения затрат на приложение «контейнер +».

— Люк Хёрстен

Хорошо, это верно. Я отказался от своего близкого голосования.

— Голо Роден

Я рад, что вы опубликовали это все же. Этот вопрос не возник в моем поиске. Статья об измерениях и показателях очень полезна: blog.docker.io/2013/10/gathering-lxc-docker-containers-metrics

— Люк Хёрстен,

Это хорошая сессия под названием «Контейнеры Linux - виртуализация NextGen для облака», в которой рассказывается о показателях производительности путем сравнения докера, виртуальной машины KVM и

— чистого

Ответы:

449

Отличная исследовательская работа IBM 2014 года « Обновленное сравнение производительности виртуальных машин и контейнеров Linux », выполненная Felter et al. обеспечивает сравнение между контейнерами из чистого металла, KVM и Docker. Общий результат: Docker практически идентичен собственной производительности и быстрее, чем KVM во всех категориях.

Исключением из этого является NAT докера - если вы используете сопоставление портов (например, docker run -p 8080:8080), то вы можете ожидать незначительное снижение задержки, как показано ниже. Однако теперь вы можете использовать сетевой стек хоста (например, docker run --net=host) при запуске контейнера Docker, который будет работать идентично столбцу Native (как показано в результатах задержки Redis ниже).

Накладные расходы NAT NAT

Они также запустили тесты на задержку на нескольких конкретных сервисах, таких как Redis. Вы можете видеть, что более 20 клиентских потоков с наибольшей задержкой идут на Docker NAT, затем на KVM, а затем на грубую связь между хостом / нативом Docker.

Docker Redis Latency Overhead

Просто потому, что это действительно полезная статья, вот некоторые другие цифры. Пожалуйста, загрузите его для полного доступа.

Взглянем на дисковый ввод / вывод:

Докер против KVM против собственной производительности ввода-вывода

Теперь посмотрим на загрузку процессора:

Загрузка процессора Docker

Теперь несколько примеров памяти (подробности читайте в статье, память может быть очень сложной):

Сравнение памяти Docker

— Hamy
источник

Что касается чисел linpack, приведенных в газете ... честно говоря, мне трудно в них поверить (не то, чтобы я не поверил, что это то, что испустил linpack, но я не верю, что тест действительно измерял только производительность с плавающей запятой, выполнила). Основные накладные расходы от KVM связаны с компонентами эмуляции аппаратного обеспечения пользовательского пространства (которые применяются только к аппаратному обеспечению без CPU ); Существуют значительные накладные расходы вокруг подкачки памяти ... но сырая с плавающей точкой? Я хотел бы взглянуть на то, что на самом деле там происходит - возможно, чрезмерные переключения контекста.

— Чарльз Даффи

Исправление для текущего синтаксиса Docker CLI: --net=host(две черты) и -p 8080:8080(строчная буква 'p') для NAT.

— bk0

Цитируемая статья IBM кажется слишком сфокусированной на сетевом вводе-выводе. Он никогда не обращается к переключателям контекста. Мы посмотрели на LXC и вынуждены были быстро отказаться от него из-за увеличения недобровольных переключений контекста, что привело к ухудшению обработки приложений.

— Эрик

Мне также любопытны операции с файловой системой - например, поиск в каталогах - это то место, где я ожидаю увидеть накладные расходы; чтение, запись и поиск на уровне блоков (на которых сосредоточены данные графики) - нет .

— Чарльз Даффи,

Я люблю диаграммы с тем же цветом. Это так легко отличить

— Виктор Жорас

105

Docker - это не виртуализация как таковая - это абстракция поверх поддержки ядром различных пространств имен процессов, пространств имен устройств и т. Д .; одно пространство имен по своей природе не является более дорогим или неэффективным, чем другое, поэтому то, что фактически делает Docker влияющим на производительность, зависит от того, что на самом деле находится в этих пространствах имен.

Выбор Docker с точки зрения того, как он конфигурирует пространства имен для своих контейнеров, имеет свои затраты, но все эти затраты напрямую связаны с выгодами - вы можете отказаться от них, но при этом вы также откажетесь от связанной выгоды:

Многоуровневые файловые системы стоят дорого - их стоимость варьируется в зависимости от каждой (и Docker поддерживает несколько бэкэндов) и с вашими шаблонами использования (объединение нескольких больших каталогов или объединение очень глубокого набора файловых систем будет особенно дорогим), но они Вы не свободны. С другой стороны, значительная часть функциональности Docker - возможность создавать гостей из других гостей методом копирования при записи и получать преимущества от хранения, подразумеваемые в одном и том же - приводит к оплате этой стоимости.
DNAT дорого обходится в масштабе, но дает вам возможность настроить сеть вашего гостя независимо от вашего хоста и иметь удобный интерфейс для переадресации только тех портов, которые вы хотите между ними. Вы можете заменить это мостом к физическому интерфейсу, но опять же потерять преимущество.
Возможность запуска каждого программного стека с установленными зависимостями наиболее удобным способом - независимо от дистрибутива хоста, libc и других версий библиотек - является большим преимуществом, но при этом необходимо загружать совместно используемые библиотеки более одного раза (когда их версии отличается) имеет стоимость, которую вы ожидаете.

И так далее. Насколько эти затраты действительно влияют на вас в вашей среде - с вашими шаблонами доступа к сети, ограничениями памяти и т. Д. - вопрос, на который сложно дать общий ответ.

— Чарльз Даффи
источник

Это хороший ответ, но я ищу более конкретные цифры и критерии. Я знаком со стоимостью cgroups, но Docker - это больше, чем вы указали. Большое спасибо за ответ.

— Люк Хёрстен

Конечно. Я хочу сказать, что любые найденные вами обобщенные тесты будут иметь очень ограниченную применимость к любому конкретному приложению - но это не значит, что я не согласен с людьми, пытающимися их предоставить, а просто с тем, что их нужно брать с кучей столовой ложки соли.

— Чарльз Даффи

Таким образом, вы можете сказать, что KVM «это не виртуализация, это просто абстракция поверх вызовов виртуальных технологий x86».

— Вад

@Vad, существует консенсусное соглашение, уходящее в прошлое на десятилетия (до ранних реализаций оборудования IBM, отличных от x86!), Согласно которому предоставление абстракции непосредственно на аппаратном уровне - это однозначно виртуализация. Консенсус в отношении терминологии в отношении пространства имен на уровне ядра значительно более фрагментирован - каждый из нас может указать на источники, поддерживающие наши индивидуальные взгляды, - но, честно говоря, существуют полезные технические различия (как в отношении характеристик безопасности, так и производительности), которые переходят на один термин Таким образом, я удерживаю свою позицию до тех пор, пока не будет достигнуто противоречие с отраслевым консенсусом

— Чарльз Даффи

@ LukeHoersten, ... верно, это не cgroups, которые имеют значительную стоимость, это гораздо больше содержимого пространства имен сети и файловой системы. Но сколько стоят эти затраты, почти полностью зависит от того, как настроен Docker - какие конкретные бэкэнды вы используете. Например, мост намного, намного дешевле, чем стандартный протокол Docker; и накладные расходы производительности различных бэкэндов файловой системы также сильно различаются (и в некоторых случаях размер накладных расходов зависит от шаблонов использования; варианты оверлейных файлов могут быть намного более дорогими с большими каталогами, измененными через несколько уровней f / e).

— Чарльз Даффи

Вот еще несколько тестов по Docker based memcached serverсравнению host native memcached serverс использованием инструмента тестирования Twemperf https://github.com/twitter/twemperf с 5000 подключений и скоростью соединения 20k

Затраты времени соединения для 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

— p4guru
источник

Они сравнивают две разные сборки memcached, а также одну из них в докере, другую вне докера, не так ли?

— Сан

Являются ли эти результаты с хост-сетью или мостовой сетью в докере?

— akaHuman

При таких больших значениях этих измерений эти данные не показывают представимых данныхavg 200.5 min 0.6 max 263.2 stddev 73.85

— Сергей Жуков