Docker容器和内存消耗 [英] Docker container and memory consumption
问题描述
Docker如何处理？
所有Docker容器是否共享停泊坞图像中定义的静态部分？
如果没有将应用程序复制到某个目录中用于运行docker容器并为每个docker容器装载此应用程序目录的机器？
Docker在内核共享资源水平。这意味着应用程序逻辑在运行时始终不被复制。如果你开始记事本1000次，它仍然只能在硬盘上存储一次，对Docker实例的计数也是一样的。
如果你运行100个相同的docker映像实例，你所做的一切都是将同一块软件的状态保持在100个不同的分离时间轴的RAM中。主机处理器将这些容器实例中的每个容器实例的内存状态移动到控制它的软件上，因此您可以消耗运行应用程序所需的RAM内存的100倍。
没有意义的存储与软件完全相同的字节代码100次，因为这部分应用程序始终是静态的，永远不会改变。 （除非你写了一些疯狂的自我更改的软件，否则你选择重建并重新部署容器的图像）
这就是为什么容器不允许持久化盒子以及docker与使用虚拟硬盘的常规VM的区别。但是，这只适用于容器内部的持久性。通过Docker软件在硬盘上更改的文件使用docker卷进行装载到容器中，因此它们不是Docker环境的一部分，而是刚装入它们。 （有关详情，请访问： https://docs.docker.com/userguide/dockervolumes/ ）
当您考虑这个问题时，您可能想要询问的另一个问题是Docker如何在运行时对其磁盘进行存储更改。什么是真正的甜蜜的检查，码头工作人员真正设法使这项工作。容器硬盘的原始状态是从图像中给出的。它可以不写入此图像。而不是写入图像，与在docker图像中的内容相比，容器内部状态的变化是一个差异。
Docker使用一种名为联合文件系统的技术，该技术在初始状态码头图像。
下面图片中的这个diff（引用为可写容器）存储在内存中，当您删除容器时，它将消失。 （除非您使用docker commit命令，否则我不建议这样做。您的新码头服务器映像的状态不会在docker文件中表示，并且不能轻易地从重建中重新生成）
Assume I am starting a big number of docker containers which are based on the same docker image. It means that each docker container is running the same application. It could be the case that the application is big enough and requires a lot of hard drive memory.
How is docker dealing with it?
Does all docker containers sharing the static part defined in the docker image?
If not does it make sense to copy the application into some directory on the machine which is used to run docker containers and to mount this app directory for each docker container?
Docker shares resources at kernel level. This means application logic is in never replicated when it is ran. If you start notepad 1000 times it is still stored only once on your hard disk, the same counts for docker instances.
If you run 100 instances of the same docker image, all you really do is keep the state of the same piece of software in your RAM in 100 different separated timelines. The hosts processor(s) shift the in-memory state of each of these container instances against the software controlling it, so you DO consume 100 times the RAM memory required for running the application. There is no point in physically storing the exact same byte-code for the software 100 times because this part of the application is always static and will never change. (Unless you write some crazy self-altering piece of software, or you choose to rebuild and redeploy your container's image)
This is why containers don't allow persistence out of the box, and how docker differs from regular VM's that use virtual hard disks. However, this is only true for the persistence inside the container. The files that are being changed by docker software on the hard disk are "mounted" into containers using the docker volumes and thus arent really part of the docker environments, but just mounted into them. (Read more about this at: https://docs.docker.com/userguide/dockervolumes/)
Another question that you might want to ask when you think about this, is how does docker store changes that it makes to its disk on runtime. What is really sweet to check out, is how docker actually manages to get this working. The original state of the container's hard disk is what is given to it from the image. It can NOT write to this image. Instead of writing to the image, a diff is made of what is changed in the containers internal state in comparison to what is in the docker image. Docker uses a technology called "Union Filesystem", which creates a diff layer on top of the initial state of the docker image.
This "diff" (referenced as the writable container in the image below) is stored in memory and disappears when you delete your container. (Unless you use the command "docker commit", however: I don't recommend this. The state of your new docker image is not represented in a dockerfile and can not easily be regenerated from a rebuild)
这篇关于Docker容器和内存消耗的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
