I've got a VM running Windows Nano and Docker containers. The Docker containers are all running ASP.NET Core 5 apps. I'm coming across this really weird bug where the VM is running out of memory, and the Task Manager, Process Explorer do not show what is taking up all this memory:
What I'm observing is that when I kill one of the containers, a lot of memory gets returned so it's definitely caused by a Docker container. The question is, how do I go about diagnosing this problem?
I've tried to take a memory dump of the app in the container I killed, but the dump is no larger than 1GB.
Related
I am running a 3d-modeling software inside a windows docker container.
In the process of a simple run, i get an exception:
Unhandled exception. (thread: (Id=2, background)) (System.AccessViolationException) Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
I have tried building from different base images to be able to run the docker in isolation=process, which I have seen suggested on threads before. I am now running off mcr.microsoft.com/windows:2004 on a windows 10 21H2 version.
Is there anyone recognizing this? If so any help would be highly appreciated.
I am trying to create a docker image from Dockerfile on Windows 10. Being new to it, it crashed multiple times due to one or more syntax errors in the Dockerfile. I tried to clear all the images by using docker system prune --all. I got some disk space cleared up (If I am right, the system here means HDD rather than RAM?). Anyway, I see that Docker.Service seems to be using 6+ GB of memory.
My question is, is there a way to clear the memory in Docker.Service? Why is it using so much of memory when no image is being used? I know that it can be cleared by exiting Docker or force closing it.
Update
By the way, I am using Linux container, there is an option when right click on the docker icon from the tray.
Update 2
I tried all the commands from their documentation page - https://docs.docker.com/config/pruning/ - No effect.
Update 3
Doesn't seem to clear even when the image is created and saved. Looks like a bug?
Docker creates an image for each command in dockerfile, it creates image layers and stores it in the cache, So whenever your dockerfile execution is interrupted the image remains in the cache. Hence you see the memory consumption.
Try the following command which will remove all the images
docker rmi $(docker images -a -q)
Docker runs Linux containers in a VM on Windows. The 6G of ram is likely what you have assigned to that VM. Use docker stats to see the resource usage of containers running inside that VM.
I have Docker image which have issues with memory leaking. It's known issue for this specific tool and authors recommend to restart nodes from time to time as a workaround.
However, daily restart is not always enough and some processed are killed by Jelastic OOM killer. I wan't not to kill them, but completely restart. If I've had real Docker running on a machine I would be able to instruct it to restart container after OOM or something like this, but in Jelastic I don't have such option.
Simple solution would be to add supervisord or something like this to my setup and take care about it but I'm wondering is there some out-of-the-box solution from Jelastic for this.
According | to | countless | sources, Docker provides ultra-lightweight virtualization by sharing system resources across containers, instead of allocating copies of those resources per container.
I've even read articles where it is boasted that you could "run dozens, even hundreds of containers on the same VM."
But if my app requires 2GB RAM to run, and the underlying physical machine has only 8GB RAM on it, I would normally only be able to run 3 instances of my app on it (leaving ~2GB for system memory, utilities, etc.).
Does Docker do some kind of magic with RAM, allowing me to actually run dozens of containers, each one allocated 2GB RAM, but somehow sharing unused memory under the hood?
Or are those statements more media hype than anything else?
When people talk about running "dozens or hundreds of containers" they are normally thinking about microservices; small applications that do a specific task. Each of these may have memory usage measured in KBs rather than MBs, and probably not GBs, and as such there is no reason a decent machine couldn't run dozens or hundreds of them.
There is actually a competition (I think it's on-going) to get as many containers as possible running on a Raspberry Pi. The result currently stands at over a thousand, but admittedly these containers won't be running a real-life application.
Regarding memory, the answer is "it's complicated". If you're using the AUFS or Overlay driver, containers with the same base image should be able to share "memory pages"; meaning shared libraries shouldn't need to get loaded twice for two containers. This isn't something special though; normal processes running on the host will work the same way.
At the end of the day, containers are little more than isolated processes. We can easily run dozens or hundreds of processes on a host, so it's not unfeasible to run dozens or hundreds of containers.
A Docker container only consumes the resources that it needs as it needs them. So yes you could literally run hundreds of machines on one box as long as they are not all actively consuming your resources. That is what makes Docker unique; the fact that a container will use what resources it can and then release them making them available for another container on the same host. It is best practice to let the container and Docker handle allocating resources instead of doing a hard assign of them.
The alternative would be a virtual machine. Each virtual machine that you run has to run a full linux kernal, and the host OS will hold a chunk of memory aside for the virtualized environment. This means that you can really only run a couple VMs on all but the heaviest duty hardware.
A container does NOT run a kernel- it just runs a single process (plus sub processes). This means that you can run as many processes in containers as you could if you were running those same processes without containers- each thinks it is running on a separate machine, but they all just show up as processes on the host kernel.
There is no magic that will make you able to use RAM dozens of times over. But you can pack smaller processes in together a LOT tighter than you could using virtual machines for seperation.
I know there are lots of docker experts around but I spent considerable time to find out some facts and figure about Docker's run time performance, but unfortunately i could not get any concrete answer. Let me start with telling you my System's configuration:
(a) Running CentOS 6.5 on a machine having 48GB RAM, 1TB Disc and 12 Core CPUs.
(b) I build up a Docker image which is having size almost 6.5GB
Below are questions if someone can answer for the benefit of readers:
(a) Now with the given configuration, question comes that how many containers I can run in parallel without break any functionality?
(b) Assume I have two Images each having size 3.5GB, then is it suggested to run multiple small size images or we get a good performance with big sized image?
(c) What is the best file systems option to use with Docker?
EDIT: more information
(d) Actually I'm trying to put many compilers inside a container and trying to give facility to users to compile their languages online. This tool is under development and will replace my existing website compileonlone.com. Things are going fine, I build up two images with few compilers in each. I'm able to run around 250 containers successfully and after that I start getting too many files opened. After 250 containers, my RAM is reaching somewhere 40GB and CPU utilization is around 50%,.
Main problem I'm facing is removal of the old containers. Because user will come and compile his code and then will go away, so I need to remove those container after certain period of time but when I'm trying to remove such stopped containers using docker rm -v, its slowing down main docker process and its almost hanging. I mean docker -d daemon which is listening at /var/run/docker.sock. Not sure if there is any other way around to clean these containers or I have a bug. Here is the detail of Docker:
# docker info
Containers: 1016
Images: 41
Storage Driver: devicemapper
Pool Name: docker-0:20-258-pool
Pool Blocksize: 64 Kb
Data file: /var/lib/docker/devicemapper/devicemapper/data
Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
Data Space Used: 17820.7 Mb
Data Space Total: 102400.0 Mb
Metadata Space Used: 102.4 Mb
Metadata Space Total: 2048.0 Mb
Execution Driver: native-0.2
Kernel Version: 3.17.2-1.el6.elrepo.x86_64
Operating System: <unknown>
WARNING: No swap limit support
If someone can help me on how to delete old containers in fastest way then it will be great. Simple shell script and all are not working. I already have tried like
#docker rm -v $(docker ps -a |grep Exited | awk '{print $1}')
but its completely slowing down main docker process and its unable to create new containers while this removal process is running.
Thanks for your time taken to answer these questions, which will help me as well as many others in going ahead with Docker.
a): A container is like a process. This question is like asking "how many processes can I run in parallel". It is not answerable without knowing what the processes are doing. Please add this information to your question.
b) Both 3.5GB and 6.5GB are very large for a Docker image. Best practice is to put one application in one container: if you have an application that size, then great. If not, maybe you have put your application's data into the image. This is not a good idea because the layered filesystem is slower than a regular filesystem, and you won't be wanting any of the features of layering or snapshotting on your transactional data.
The documentation on managing data explains how to mount regular disk so it is accessible from your containers.
Edit, after more information was supplied
d) Using up RAM implies the containers are still running. If there is some way within the logic of your site to know when a container is no longer needed you can docker kill it, then docker rm to remove the disk storage. Or docker rm -f does those two operations in one.
After a lot R&D and discussing with many experts, I found a solution to delete containers with lightening speed. Its simple you have run your docker daemon with dm.blkdiscard=false option as follow.
docker -d --storage-opt dm.blkdiscard=false
By the way here is what I have developed. Here I need to create and delete containers with a high speed
http://codingground.tutorialspoint.com
Hope this will help many others.