Mac os docker тормозит

Докер в MacOs очень медленный

У меня есть этот docker-compose.yml:

Когда я запускаю на нем свой новый проект в Symfony 4, он работает очень медленно. 🙁

У меня есть новые MacOs и Docker Desktop. В настоящее время я изучаю фреймворк Symfony и Laravel, но это очень медленно для Docker. Это даже не работает над этим.

Как я могу это починить?

На самом деле, для запуска Docker необходимо простое Linux kernel . К сожалению, Mac OS и Windows не могут обеспечить это. Поэтому в Mac OS есть клиент для запуска Docker. В дополнение к этому, существует уровень абстракции между ядром Mac OS и приложениями (контейнеры Docker), а файловые системы не одинаковы. Из-за этого Docker работает на Mac OS медленно. Вы не можете запустить Docker в Mac OS, как в Linux.

Если мне нужно привести несколько примеров о реальных случаях использования. У меня такая же машина. Итак, я использую Symfony 4 на Docker v18 на Mac OS Mojave. Это мое общее время выполнения Symfony на Docker. (Очевидно, это зависит от вашего внешнего интерфейса и запросов к базе данных, но я пытаюсь объяснить вам основную логику.)

первый раз рендеринг 12000 мс с кешем Symfony: 344 мс с кешем Docker (: свойство cached для Docker для томов): 195 мс

Пока я использую Symfony без Docker, вот мое общее время выполнения.

без докера, с кешем Symfony: 82 мс

Принимая во внимание, что мы могли бы сделать некоторые улучшения, чтобы улучшить рабочее пространство. Например, вы можете использовать такие объемы, как это,

Источник

Что такое dinghy или как ускорить docker

Однажды я заглянул на Хабр, чтобы посмотреть как разработчики используют динги (dinghy) и вообще ускоряют работу докера на маке. На моё удивление по запросу динги я нашёл ровно ноль статей. Было бы нечестно не упомянуть, что тот же запрос вывел 4 комментария. С другой стороны этот факт не изменил картины в целом.

Так вышло, что динги очень удачно вписался в мой технологический стек, а так же помог мне решить некоторые проблемы, самые важные из которых:

• Производительность докера на osx
• Запуск нескольких контейнеров, которые работают на порте 80

Под катом более подробное описание вышеперечисленных проблем, а так же способы их решения.

Проблема 1: низкая производительность докера на маке

Поскольку докер написан поверх линуксовсого ядра, для других ОС необходимо использовать виртуальные машины. Это, в свою очередь, негативно сказывается на производительности вашего рабочего окружения. Действительно, теперь, чтобы ваши изменения попали в контейнер вам необходимо предпринять дополнительные шаги.

Docker toolbox

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

В моём случае тулбокс оказался достаточно медленным. Данный инструмент хорошо подходит для запуска «статических» контейнеров. Когда же нужно интенсивно разрабатывать приложение, необходимо создавать mounted volumes (уже давно пытаюсь найти русский эквивалент, есть идеи?) вашей рабочей директории, то есть директории с кодом вашего приложения. И вот тут начинаются проблемы. Выяснив, что тулбокс не использует ни NFS ни rsync, я стал искать другие решения.

Преимущества:
— легко устанавливается и настраивается
Недостатки:
— медленный при разработке больших проектов

Docker for mac

В отличие от тулбокса, докер для мака не использует виртуал бокс. В качестве слоя виртуализации он использует HyperKit. Особенность — вы можете использовать только одну виртуальную машину. Впрочем, если необходимо, вы можете запустить докер для мака параллельно с тулбоксом.

К сожалению, докер для мака оказался ещё медленней. Никакого очевидного (и неочевидного) способа как ускорить сие приложение я не нашёл.

Преимущества:
— ещё легче устанавливается и настраивается
Недостатки:
— ужасно медленный

docker-osx-dev

Хорошее решение для ускорения работы на локальных машинах при работе с тулбоксом. Docker-osx-dev использует rsync, что значительно ускоряет отправку изменений в контейнер. Недостатком данного решения можно назвать «раздутый» размер контейнера, поскольку сами файлы копируются в контейнер.

Поэтому, используя данный подход, необходимо позаботиться о виртуальной машине с увеличенным объёмом памяти. Кэши, билды, логи — всё будет увеличивать объём памяти.
Другим недостатком я бы назвал процесс, висящий в терминале. Бэкграунд режим по умолчанию не поддерживается.

Преимущества:
— значительно ускоряет перенос файлов в контейнер
Недостатки:
— висящий процесс
— раздувает размер контейнера

Dinghy

Dinghy — это надстройка над докер машиной (docker-machine), которая включает в себя NFS и proxy (о котором мы поговорим чуть позже, cейчас нас интересует проблема производительности). А насколько мне известно, ничего быстрее NFS (в данном контексте) ещё не придумали.

Теперь, вместо создания и использования дефолтной или бут ту докер виртуальной машины, мы создаём динги машину. По умолчанию в ней уже будет включен NFS. Если вы не хотите использовать прокси, то можно его отключить в настройках динги, поставив соответствующий флаг в true:

Недостаток: поскольку вы явным образом импортируете переменные окружения (например export DOCKER_MACHINE_NAME=dinghy и пр.), то использование обычных докер машин параллельно с динги может принести много хлопот.

Преимущества:
— скорость работы
— никаких дополнительных процессов
Недостатки:
— возможно потребуются дополнительные конфиги (docker-compose.yml)
— конфликт DOCKER_MACHINE_NAME с обычной докер машиной

Проблема 2: приложения на 80 порту

После того, как мы ускорили работу своей рабочей среды, может появиться ещё одна проблема: необходимость иметь 2 и более контейнеров, работающие на 80 порту. Что за проблема, просто взять и заэкспойзить другой порт, — может сказать внимательный читатель. Действительно, зачастую данного решения бывает достаточно. Но иногда, конфигурация проектов достаточно сложна и запутана. В этих случаях необходимо иметь именно 80 порты.

Что же, хорошие новости, ведь в динги по умолчания включен прокси. Вместе с запуском виртуальной машины динги, вы можете заметить всегда запущенный контейнер:

Этот контейнер слушает на 80 порту и принимает все запросы на себя. Внутри этого контейнера имеется nginx сервер, который автоматически создаёт виртуальные сервера исходя из вашего docker-compose файла. Всё, что вам нужно, указать hostname в этом файле. Далее, при обращении на данный хост, динги найдёт нужную запись и перенаправит на нужный контейнер. Профит.

Заключение

Изначально я планировал привести больше технических подробностей, примеры конфигураций и скриптов, но по ходу написания статьи понял, что ушёл немного в другое русло. К тому же она получилось бы слишком длинной, наверное. При этом я ответил на поставленные вопросы и очень надеюсь, что данная статья оказалась вам полезной и/или интересной.

Если у вас возник интерес по техническим деталям, оставляйте комментарии, постараюсь на всё ответить.

Спасибо за внимание.

Обновление от 18.09:
после обсуждения в комментариях с umputun удалил из недостатков докера для мака:
— только одна виртуальная машина, настраиваемся самим приложением

Источник

Speeding up Docker on MacOS

Roughly a 6 minute read by Matthew

If you’ve moved your development environment to Docker, you might have noticed your web application stacks might be slower than another native environment you’ve been used to. There are things we can do to return your response times back down to how they were (or thereabouts).

Overview

1. Volume optimisations
Modify your volume bind-mount consistency. Consistency cache tuning in Docker follows a user-guided approach. We prefer delegated for most use-cases.

2. Use shared caches
Make sure that common resources are shared between projects — reduce unnecessary downloads, and compilation.

3. Increase system resources
Default RAM limit is 2GB, raise that up to 4GB — it won’t affect system performance. Consider increasing CPU limits.

4. Further considerations
A few final tips and tricks!

Introduction

Most of our web projects revolve around a common Linux, Nginx, MySQL, PHP (LEMP) stack. Historically, these components were installed on our machines using Homebrew, a virtual machine, or some other application like MAMP.

At Engage, all our developers use Docker for their local environments. We’ve also moved most of our pre-existing projects to a Dockerised setup too, meaning a developer can begin working on a project without having to install any prerequisites.

When we first started using Docker, it was incredibly slow in comparison to what we were used to; sharp, snappy response times similar to that of our production environments. The development quality of life wasn’t the best.

Why is it slower on Mac?

In Docker, we can bind-mount a volume on the host (your mac), to a Docker container. It gives the container a view of the host’s file system — In literal terms, pointing a particular directory in the container to a directory on your Mac. Any writes in either the host or container are then reflected vice-versa.

On Linux, keeping a consistent guaranteed view between the host and container has very little overhead. In contrast, there is a much bigger overhead on MacOS and other platforms in keeping the file system consistent — which leads to a performance degradation.

Docker containers run on top of a Linux kernel; meaning Docker on Linux can utilise the native kernel and the underlying virtual file system is shared between the host and container.

On Mac, we’re using Docker Desktop. This is a native MacOS application, which is bundled with an embedded hypervisor (HyperKit). HyperKit provides the kernel capabilities of Linux. However, unlike Docker on Linux, any file system changes need to be passed between the host and container via Docker for Mac, which can soon add a lot of additional computational overhead.

1. Volume optimisations

We’ve identified bind-mounts can be slow on Mac (see above).

One of the biggest performance optimisations you can make, is altering the guarantee that file system data is perfectly replicated to the host and container. Docker defaults to a consistent guarantee that the host and containers file system reflect each other.

For the majority of our use cases at Engage we don’t actually need a consistent reflection — perfect consistency between container and host is often unnecessary. We can allow for some slight delays, and temporary discrepancies in exchange for greatly increased performance.

The options Docker provides are:

The host and container are perfectly consistent. Every time a write happens, the data is flushed to all participants of the mount’s view.

The host is authoritative in this case. There may be delays before writes on a host are available to the container.

The container is authoritative. There may be delays until updates within the container appear on the host.

The file system delays between the host and the container aren’t perceived by humans. However, certain workloads could require increased consistency. I personally default to delegated, as generally our bind-mounted volumes contain source code. Data is only changing when I hit save, and it’s already been replicated via delegated by the time I’ve got a chance to react.

Some other processes, such as our shared composer and yarn cache could benefit from Docker’s cached option — programs are persisting data, so in this case it might be more important that writes are perfectly replicated to the host.

Источник

Нормально ли что при работе через Docker у меня заметно тормозит app?

Доброе время суток!

Начал изучать докер. После суток мучений я запустил проект в полном стеке с использованием докера. Но теперь я вижу увеличение времени ответа от сервера. App работало моментально на локальной машине на стандартном стеке nginx + php-fpm 7 + mysql. После настройки подобного стека на докере все работает заметно медленнее. Как можно это пофиксить?

• Вопрос задан более трёх лет назад
• 3106 просмотров

Сделал как вы сказали, запустилась виртуалка, запустил docker compose up
Все собралось.

В хост машине прописал

Не удается получить доступ к сайту

Сайт mooraway.dev не позволяет установить соединение.
Возможно, вы имели в виду moodaway.com/.
Выполните поиск по запросу mooraway dev в Google
ERR_CONNECTION_REFUSED

Что не так сделал?

/Documens/www и все ок стало.

Docker — это средство контейнеризации исключительно Linux (хотя и FreeBSD можно там взвести внутри).
Таким образом, изнчально нам нужно РАБОТАЮЩЕЕ ядро Linux.
Если вы используете Docker под Linux — проблем с этим нет. Запуск контейнера почти мгновенный.
Если вы используете Docker под Windows или MacOSX, то нужно сначала загрузить сам Linux для того, чтобы уже там загружать контейнеры.
В реальных системах боевых — Docker запускают ТОЛЬКО на Linux серверах. Но для отладки вы можете делать это где угодно. Только смиритесь с тем, что если это будет не под Linux, то запуск будет долгим.

Под Linux запуск приложения в Docker — это всего лишь контейнер, то есть всего лишь изоляция вызовов API операционной системы.

Под не-Linux запуск приложения в Docker требует изначально запуска самого Linux в виртуальной машине.

то есть Docker — под Linux?

вы часом, файлы БД и логов не в слоеную FS запустили?
так нельзя делать.

вы часом, файлы БД и логов не в слоеную FS запустили?
так нельзя делать.

Не понял, выше docker-compose

markmoskalenko, ну во первых на Mac — это будет через ВИРТУАЛКУ.
Какие тесты производительности тут могут быть.
Как вариант — поставить в виртуалку драйвера паравиртуализации и включить паравиртуализацию, тогда скорость должна подняться.

Docker-Compose или не Compose не означает что у вас данные лежат правильным образом.

При корректной настройке НИЧЕГО не должно писаться внуть контейнеров Докера. Все что пишется на диск — только подключенные внешние папки должны быть.

Источник