Docker Community Forums

Share and learn in the Docker community.

Connection to database container very slow after updating Docker for Mac

docker

(Unadivadantan) #1

I just updated my Docker for Mac last week. I’m now using 1.12.3. Before, the connection to the database container was normal but after the update it became extremely slow. It can take about 10 minutes to update the schema of a Symfony application, for instance. Or about 10 minutes to import the dump of another SQL database. I read that using the IP instead of the container’s alias on the app could be a solution but it changes nothing for me. Is this a known issue? If not, where can I have more information about what’s happening?

The post where I read about the IP: http://stackoverflow.com/questions/40273330/docker-slow-non-local-database-access

Thank you.


(David Sheets) #2

You may be experiencing https://github.com/docker/for-mac/issues/668 which has a workaround.


(Unadivadantan) #3

Thanks for your answer @dsheets. I think that’s exactly the problem I have. I’m downloading the beta version to test as I cannot go back to an older stable version.


(David Sheets) #4

The latest stable (1.12.3) should have the workaround as well.


(Unadivadantan) #5

That’s the one I was using and where I found the bug. That’s strange.


(David Sheets) #6

Sorry, I might have been ambiguous: there is an issue. In the default (safe) configuration, it causes a performance degradation. Both the current Beta (since 27) and the current stable (since 1.12.3) have a toggle as described in the second link above (comment in 668). This toggle will improve performance at a detriment to safety. We’re working on having both performance and safety for the virtual block device but that work is still ongoing. Sorry for the confusion.


(Unadivadantan) #7

Ah ok, thank you! I’ll keep the stable version though. If I understood well the issue on Github the solution is simply to run this command on the server?

echo false > com.docker.driver.amd64-linux//full-sync-on-flush


(David Sheets) #8

No, you need to run the full sequence of commands in the workaround including the git commands in the correct directory.