tkasidakis@tkasidakis-HP-Pavilion-Gaming-Laptop-15-cx0xxx:~$ sudo lxc image list
+--------------+--------------+--------+---------------------------------------------+--------------+-----------+-----------+-------------------------------+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE | UPLOAD DATE |
+--------------+--------------+--------+---------------------------------------------+--------------+-----------+-----------+-------------------------------+
| DetectionSvc | 6e6260b3414a | no | Ubuntu 18.04 LTS server (20200722) | x86_64 | CONTAINER | 2389.11MB | Nov 10, 2020 at 12:08pm (UTC) |
+--------------+--------------+--------+---------------------------------------------+--------------+-----------+-----------+-------------------------------+
| | 6063f2011ba1 | no | ubuntu 18.04 LTS amd64 (release) (20201031) | x86_64 | CONTAINER | 189.70MB | Nov 10, 2020 at 11:28am (UTC) |
+--------------+--------------+--------+---------------------------------------------+--------------+-----------+-----------+-------------------------------+
The above measurements are derived from doing
sudo lxc launch DetectionSvc DetectionSvc
When i did
lxd init
i choose zfs as storage policy
Are the above measurements OK as far as the launch time is concerned. Is there a way to reduce the above numbers ? Maybe if i start the container with limited resources ?
I want to achieve as smaller launch time as i can with the DetectionSvc image.
So is that image being download or is it local? Is this the first time you have a launched a container on that storage pool? If so then it will be unpacking the image tarball onto the ZFS pool before creating an optimized snapshot which will be used to create subsequent containers from the same image.
The image is local. The first time which i launched the container took a lot, meaning the first time launching a container under zfs storage pool. All the other times took more or less 8 seconds. I dont have many containers. The container is one . DetectionSvc .
After the creation, i stop the container and then i am deleteting.
All this operations have a significant time gap among them.
So should i stick with the 8 seconds as a good number which can not be reduced further more right ?
No that is not a good time, here is a test on my local PC (nothing special, sata SSD drive using a non-optimized loopback image ZFS pool).
The images:ubuntu/focal image is already downloaded locally, so my internet speed doesnât factor into it.
# Create fresh ZFS storage pool using a loopback image onto the host's filesystem (not very performant compared to using a dedicated driver/partition)
lxc storage create zfstest zfs
Storage pool zfstest created
# Create new container on new pool, this will unpack the image into a ZFS volume and then snapshot it for creating containers from. But won't start the container.
time lxc init images:ubuntu/focal ctest1 -s zfstest
Creating ctest1
real 0m5.890s
user 0m0.052s
sys 0m0.012s
# Start the container.
time lxc start ctest1
real 0m0.405s
user 0m0.014s
sys 0m0.008s
# Delete the container
lxc delete -f ctest1
# Recreate the container (using the existing optimized snapshot volume):
time lxc init images:ubuntu/focal ctest1 -s zfstest
Creating ctest1
real 0m0.614s
user 0m0.055s
sys 0m0.015s
So you can see even on my not partcularly fast system, it is performing must faster than your tests.
I would suggest you enable debug logging and see which steps are taking longest. Also ensure you differentiate between lxc init (which creates a container) and lxc start which starts a container.
The lxc launch command does both a create and a start in one go. So not useful for testing.
To tell you the truth, I am a little bit confused . I understand fully your example, but is the launch command so bad that produces so bad times ?
In my case, i want exactly this : both creation and start of a container.
If i add your measured time above is way far from 8,2 secs.
The same operation as yours in my laptop ( meaning starting a container from a plain ubuntu image which is available locally so network is omitted) takes about 5 secs .
The fact that i am using HDD can cause some much overhead ?
What I was trying to explain was that if you are trying to find the cause of the slow down you would be better off using lxc init and then lxc start and seeing which one introduces the slow down.
Yes yes i will used it definitely Thomas. I am just waiting to upload the DetectionSvc.tar.gz to a VM which has CentOS and is quite powerfull in order to see the behavior of launch command there. I will be back with a detailed post and debugging info refering also to the platform that i used
root@tkasidakis-HP-Pavilion-Gaming-Laptop-15-cx0xxx:~/Desktop time lxc launch DetectionSvc DetectionSvc -s zfstest
Creating DetectionSvc
Error: not found
real 0m0,057s
user 0m0,030s
sys 0m0,031s
The init procedure of the DetectionSvc container took about 2 secs.
The start procedure of the DetectionSvc container took about 6 secs.
When i perform launch command, it took 8 secs which seems reasonable.
Thomas i did exactly what you did with zfstest but it didnât improve my times.
I believe that the fact that i am using HDD instead of SSD doesnât help me with my time measurements.
These are good questions and indeed it is likely that they affect launch time.
However, the real issue is how much of an effect it has to the launch time.
That is, is the launch time difference that significant so that you would need to consider to adjust cpu and memory for a container?
You can easily test these and make a table of the results. In fact it would be good to get the results here. You can put the results in a table in Markdown by following this generator, https://www.tablesgenerator.com/markdown_tables
I will do it definitely simos. In order to have fair results i should adjust a profile with the specific limits. I want to put to a profile the minimum cpu and memory limits in order to start the container. Can you help me a bit with this please ?
Is there a way to combine the default profile with a profile which makes a container to have limited resources ?
Those logs are not showing which part is taking the time. It suggests you are missing the important bits before âMountInstance finishedâ.
For example if I run lxc launch images:ubuntu/focal c1 I see many lines, but these are the important parts that occur after the imagr has been download, but as it is being unpacked into the first ZFS volume to create the optimized volume to create the first container from.
