Why does the base dump take a long time to import in docker?

Question

MySQL

Good afternoon.
There is a 50mb database dump, it takes a very long time to import into the database.
Compared with a virtual machine running in Virtualbox. in VB import takes 2-3 minutes, against 15-20 in docker.
The files are divided into volumes as follows

volumes:
      - ./data:/var/lib/mysql
      - ./dump:/docker-entrypoint-initdb.d

How can I speed up importing a database in docker so that it works at about the same speed as outside the container?
OS xubuntu 18.04

Answer 1

In general, docker gives a slightly specific load to the host. I mean, without docker, most processes are the ancestors of their children, but in the case of docker, those same ancestors are also children of processes, such as containerd.
At the same time, your OS does not quite understand what is happening. Previously (without docker), the user started daemons, each of which was a child of the init.d process, and now the user decided to start some strange service (like /usr/bin/containerd) and began actively branching children to children with it, those more children for children :)
"So how can I distribute the load generated from all this kindergarten towards your hard drives, dear user?" your OS asked.
Let's tell her. And let's say something like this:"Dear OS! Please distribute the resources of hard drives (especially SSDs) according to the principle "who gets up first, that's the sneakers !
"
We save the file. Write changes to the bootloader:
Reboot the host.
elevator=noop proper - sets noop as the kernel's default I/O scheduler. Noop - forms the entire stack of commands towards your HDD in the form of a FIFO queue, which works in the way we need - "who gets up first, that's the sneakers." You will notice the increase in OLTP operations in the database right there.
transparent_hugepage=never - you don't have to set it, this parameter turns off the regular THP mechanism, which on cloud hosting forms a generally larger load on the host than we would like to see. It will not strongly affect the record in the database if there are no powerful loads. If the load is steep, it makes sense to turn off this mechanism.
"And what kind of muck is this docker of yours? What do I need to do - now configure each virtual machine when creating it in such intimate places?" - you ask.
I will answer.
Linux is a free OS for a wide range of tasks. It is not windows, it will not hardcode for you all the kernel parameters, which may differ within the framework of these very tasks solved on your host. And then - colossally buggy without options. Linux - is put even on washing machines, refrigerators, and God knows where else. Your job is to tell the OS what you're doing. OS - will not let you down. In turn, the developers of the dockerd and containerd services cannot be held responsible for the behavior of their product on hosts running on boxed settings. Docker - gives you an ecosystem that allows you to solve very cool tasks faster than a seasoned old believer system administrator can do it with his hands in the console.
You can document the necessary host settings in confluence, write detailed step-by-step instructions - what needs to be done with the OS after installation, so that everything flies on it. Convenient, I advise. You can look at the Teraform product, which can help you automate the creation of pre-configured industrial quantities of hosts.
Something like this. Try :)

Answer 2

Docker and intensive writing to disk is a separate story, no one deploys intensively writing applications in the docker.