compose: Docker-compose run significantly slower than docker run
I’ve noticed that docker-compose run
seems to be significantly slower than plain docker run
. Based on verbose logs it looks like it’s slow due to docker resize
command.
See example:
See logs https://gist.github.com/Maxim-Filimonov/7c90d303d102a0074c32
Additionally i’m not sure is that a problem with my specific terminal but i’ve noticed that docker-compose run
does not start terminal prompt until I type something into it. In the gif you can see me typing pwd otherwise it just sits there without prompt forever.
About this issue
- Original URL
- State: closed
- Created 9 years ago
- Comments: 40 (6 by maintainers)
I have docker-compose 1.7 on Mac OSX. I figured out that it comes (in my case) from my home network, but I cannot find why:
So it clearly comes from my home network, as I cannot reproduce it from work network. But what is happening there…
The previous version of the beta docker for Mac OS also had problems with my network (could not pull any images), but since the last update of the beta, no issue anymore. I don’t know if this is related or not, just giving everything I observed.
Any suggestions in 2019 regarding how to run the tests without the very slow setup of docker-compose?
Same issue on my Raspberry Pi 3 using Raspbian. Even on simple commands like showing the version, where not much work should be done, I got very slow responsiness:
I installed docker-compose using pip as recommended in the official documentation. The latest Raspbian image at the time of writing is used:
same issue on mac. docker-compose version 1.5.2, build 7240ff3
I was blaming docker lately for being so slow for running phpunit, but tested it without docker-compose and was blazing fast, docker-compose is not usable for running tests, it takes more time for the container to actually run than the time needed for the tests. This needs to be fixed.
Not sure if this is the correct issue to post this but I’ve noticed considerable lag when building images.
docker-compose build
will sit for minutes sporadically on various steps. While I sit waiting 10 minutes for a step to complete the target machine is pretty much idling, CPU usage being well under 1% with a Gig of ram to spare. It won’t consistently lag on a particular step, it will run at “normal” speed and then decide to take a really long breather.Server:
Client:
Same issue here with latest docker and latest docker-compose. Starting a rails console takes 12s when docker-compose up is used and about twice the time when docker-compose run is used. Really strange. How can I help to debug this?
Hint: If I add privileged: true to the docker-compose.yml, up and run are equally fast!
I solveld this question staying my Dockerfile in sub-folder.
php: restart: always
build: . ports:
db: restart: always image: mysql:5.6 ports: - “3306:3306” environment: MYSQL_ROOT_PASSWORD: 123 DB_NAME: pass DB_PASS: 123 DB_USER: pass volumes: - ./mysql/databases:/var/lib/mysql - ./logs/mysql:/var/log/mysql
to
php: restart: always
build: ./php ports:
db: restart: always image: mysql:5.6 ports: - “3306:3306” environment: MYSQL_ROOT_PASSWORD: pass DB_NAME: test DB_PASS: pass DB_USER: test volumes: - ./mysql/databases:/var/lib/mysql - ./logs/mysql:/var/log/mysql
I am also running into a 2X performance hit when comparing
docker-compose up
vsdocker-compose run
. I have a mongo, rabbit, mysql, and test containers where the test container interacts with mongo, rabbit and mysql. We run java gradle unit tests in this test container that produces a lot of log output to STDOUT. When I run using “up” the tests take about 12 minutes when using “run” it takes 24 minutes to execute. I was preferring the “run” option as I plan to execute this in jenkins but considering the performance issues I’ll have to use “up” and put the process in the background and monitor it until it’s done before finishing the jenkins job. Is there a chance when you use “run” it uses a different network resulting in slower communication as it does talk to mongo and rabbit a lot. Any ideas or suggested approaches for this?@thaJeztah Yes, sure!. The issue is #3419
No, I’m running ubuntu.