What is the difference between the size and the virtual size of the docker images?
Asked Answered
H

3

24

I have a private registry where I store all of my docker images.

I noticed that when I pull an image from it,the difference in the sizes of the image on my local machine and the one on the registry is significant.

For example,I have an image called mydb (around 126 MB).

When I pull it on my local machine and execute "docker images", it says that the "VIRTUAL SIZE" of that image is now almost three times larger (388 MB).

I was wondering what is the the reason for it and what "VIRTUAL SIZE" actually means.

Thank you :) .

Hathorn answered 22/6, 2016 at 11:39 Comment(0)
D
25

You can find a good explanation of this concept here: https://github.com/docker/docker.github.io/issues/1520#issuecomment-305179362

From thaJeztah

The "size" and "virtual size" describe the amount of disk space used by a container. Let me try and explain:

When starting a container, the image that the container is started from is mounted read-only. On top of that, a writable layer is mounted, in which any changes made to the container are written.

The read-only layers of an image can be shared between any container that is started from the same image, whereas the "writable" layer is unique per container (because: you don't want changes made in container "a" to appear in container "b" smile)

Back to the docker ps -s output;

The "size" information shows the amount of data (on disk) that is used for the writable layer of each container The "virtual size" is the total amount of disk-space used for the read-only image data used by the container and the writable layer. The reason it's named "virtual size", is that (as described earlier), the disk space for the read-only layer(s) can be shared between containers, so only take up disk space once (perhaps a different name ("shared" size?) would have been better in hindsight, but naming is hard :) ). edit: virtual actually shows the combined size of the readonly layer (the image), and the writable layer of the container.

In the example below, I started 10 nginx containers;

enter image description here

All these containers use the same image, so the "Virtual size" (183MB in the example) is used only once, irregardless of how many containers are started from the same image - I can start 1 container or a thousand; no extra disk space is used. The "Size" (2B in the example) is unique per container though, so the total space used on disk is:

183MB + 10 * 2B

Be aware that the size shown does not include all disk space used for a container. Things that are not included currently are;

  • disk space used for log-files (if you use the json-file logging driver) - which can be quite a bit if your container generates a lot of logs, and log-rotation (max-file / max-size logging options) is not configured
  • volumes used by the container
  • disk space used for the container's configuration files (hostconfig.json, config.v2.json, hosts, hostname, resolv.conf) -
    although these files are small
  • memory written to disk (if swapping is enabled)
  • checkpoints (if you're using the experimental checkpoint/restore feature)
Dorotea answered 18/7, 2018 at 21:38 Comment(3)
Its always a good idea to also quote the essential info from a link (in case link goes dead; and to give future readers a "starting point" from which to grasp what is said at the link.) From that link: "The "size" information shows the amount of data (on disk) that is used for the writable layer of each container. The "virtual size" is the total amount of disk-space used for the read-only image data used by the container and [plus] the writable layer."Millard
I just noticed that the link is about size of container, whereas the question is about size of image. I don't know enough to state whether the meaning of size/virtual size is exactly the same for both container and image. Frankly, I don't even know what "virtual size" would mean for an image, unless it means "the virtual size that a container made from this image would have". That is, the size of memory space accessed within the container, which is the sum of read-only image data (shared by all instances of that image) plus the container's writable layer (each instance needs their own).Millard
So the disc space is shared but what about the RAM? Every process stack has its own copy of the underlying program? @geige vExtortionate
R
0

Now, the explanation of "VIRTUAL SIZE" of container can be found in the official documents.

(But i don't know whether there is virtual size for images.)

https://docs.docker.com/storage/storagedriver/#container-size-on-disk

To view the approximate size of a running container, you can use the docker ps -s command. Two different columns relate to size.

  • size: the amount of data (on disk) that is used for the writable layer of each container.
  • virtual size: the amount of data used for the read-only image data used by the container plus the container’s writable layer size. Multiple containers may share some or all read-only image data. Two containers started from the same image share 100% of the read-only data, while two containers with different images which have layers in common share those common layers. Therefore, you can’t just total the virtual sizes. This over-estimates the total disk usage by a potentially non-trivial amount.
Ries answered 4/3, 2023 at 10:42 Comment(0)
F
-5

There is no mystery about "virtual" size and regular size, but you should remember that images have intermediate images or "cache" if you will. So the virtual size of an image is the one you see with:

docker images

And the image disk size of an image is the sum of all cached images associated with this one, you can see that with:

docker images -a
Fend answered 22/6, 2016 at 18:7 Comment(1)
Unfortunately, this answer mixes up the topics of intermediate layers with virtual vs non-virtual size. IMHO this simply adds confusion to the topic, and would best be removed by the author. (Its already been downvoted by someone else; I'm just giving my opinion as to why it isn't useful.)Millard

© 2022 - 2024 — McMap. All rights reserved.