-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MySQL extremely slow just with docker-ce installed #247
Comments
I'm also having this issue with Docker mysql containers on google container engine and on linux- Centos7. The original build of database is fast querying, the dump to a new one on my linux local machine is fast, but the docker container in either environment is 20+ times slower no matter if I load sql dump from docker-entrypoint-initdb.d or |
Same here. Running a PHP with Symfony app on "bare metal" is way faster than running the exact same in a docker container on the exact same host. The MySQL dir (/var/lib/mysql) is mounted via bind to a local directory. I'm experiencing this with MariaDB:10.1 as well as MySQL (latest) and on Linux (debian) and MacOS. The performance difference is so dramatical that I'm unwilling to convert the app to a dockerized instance. MacOS: Server: Linux: Server: |
I believe I am experiencing the same issue, even thought this sound really weird. Came from a Fedora 26 with older docker and upgraded to Fedora 27 installed docker-ce. So yes newer OS and other version of docker. I will try to reproduce by uninstalling . I am running btrfs, but since that wasn't an issue under F26... Also tried the mysql on the raw F27 but this was also slow (while docker engine was still running) |
I've been trying to reproduce this problem with different distributions. using the OP's way:
So far i could...
I thought there was a pattern emerging with the headless distributions until I installed gnome on Centos. |
When testing Fedora I've found something interesting: MariaDb was already slow on Fedora 27 Workstation without docker installed. But it was the same slowness (3m+) as I get on Ubuntu desktops with docker-ce installed. So when one can find what Fedora Workstation and Ubuntu Desktop with docker have in common, this could be further triangulated. |
I have the same issue on centos 7.4 with xfs and debian 8 with ext4. It looks like mysql bug #46959. The solution for me is set nobarrier for xfs and barrier=0 option for ext4 in /etc/fstab. |
@dypa It did not work for me. |
Could this be related to cgroups settings for Desktop vs Server and know how to change this? |
I also got the same issue using docker in ubuntu server, idk if it works for you: |
I've tried setting barrier=0 on the ext4 disk on Ubuntu Desktop and Fedora Workstation. Both without improvement of the mysql-speed. |
Same issue. mysql -h 127.0.0.1 -u user -p db < data.sql In host machine, this just takes 5 mins, but in docker, it takes more than 30 mins and just inserted about 50,000 rows data. |
I have the same issue on Ubuntu 16.04 and Docker |
I have this issue since i updated ubuntu from 17.10 to 18.04. (desktop version) Dev machine : i7 7700k, 16GB RAM Edit: Performances are back to normal, but I'm not sure how... I tried to use a volume on another SSD for /var/lib/mysql in my compose file : mysql:
build:
context: ./docker/docker/mysql/
dockerfile: MariaDB-10.Dockerfile
volumes:
- ./mysql/:/var/lib/mysql Deleted mysql container and up I revert to default storage and applied advices from this thread : echo 0 >/sys/block/sda/queue/iosched/slice_idle
echo 0 >/sys/block/sda/queue/iosched/group_idle Deleted mysql container and up I reverted back the IO schedulers and populate my DB (without deleting/restarting containers) and was expecting 20 seconds but no : echo 1 >/sys/block/sda/queue/iosched/slice_idle
echo 1 >/sys/block/sda/queue/iosched/group_idle 2.2 seconds EDIT : as noticed by @hriad, default value was 8, so when I set to 1, I didn't restore original value ;) What change did restore performances ? I don't know, but if it can help someone... |
@wollanup You nailed it dude. I've a smilar dev machine and been strugling with this issue since a few months now. After reading your findings, I ran integration tests on a laravel app I'm working on with mysql on docker, it took 14 minutes to complete. I then set slice_idle and group_idle to 0 and ran the same test suite again, it completed within 4 minutes. However, as you noted setting those values back to 1 didn't impact performance, because (at least in my case) group_idle default value is set to 8 not 1. Setting it back to 8 gets me the same level of initial performance. After digging a bit more https://wiki.archlinux.org/index.php/Improving_performance#Changing_I.2FO_scheduler. I did reset slice_idle & group_idle back to their default values and changed the IO scheduler from cfq to noop and my test suite is runing within the 4 minutes mark. So far I didn't notice any negative impact on disk performance. |
@hriad You're right about the default value 8 set to group_idle.
And again, setting this value to 0 restores blowing fast SQL INSERTs...
|
On our new Ubuntu 18 development VM we had the same issue again. Following this article and setting the I/O-scheduler to "noop" solved it for us: https://blog.codeship.com/linux-io-scheduler-tuning/ (Our functional php unit tests with lots of SQL went from 13 minutes with the cfq-scheduler down to under 2 minutes with the noop-scheduler.) |
Changing the scheduler to |
Running OPTIMIZE on the table or fix the whole db, see: https://stackoverflow.com/a/23944159/2867894 |
Expected behavior
MySQL fast with docker-ce installed as it is without docker-ce installed.
Actual behavior
MySQL on Ubuntu becomes extremely slow just by having docker-ce installed.
Steps to reproduce the behavior
We have also tried to use the mysql docker containers from https://hub.docker.com/r/mysql/mysql-server/ and https://hub.docker.com/_/mysql/ on a clean Ubuntu with the same slow result.
We have tried to find an explanation and found other people with a similar problem (e.g. https://forums.docker.com/t/mysql-slow-performance-in-docker/37179). However, we did not find any post describing the slowness already occurring outside the docker container as demonstrated by our reproduction guide above.
We hope that this might be the clue needed to figure out why this is happening. This obviously is not a problem from the containers.
Environment
The text was updated successfully, but these errors were encountered: