Difference between revisions of "WP/Containers density"
< WP
| Line 5: | Line 5: | ||
== What makes containers to be perfectly suitable for high density? == | == What makes containers to be perfectly suitable for high density? == | ||
| − | # Containers do not reserve memory assigned to it. They exhibit elastic behavior, if applications do not use | + | # Containers do not reserve memory assigned to it. They exhibit real-time elastic behavior, if applications do not use memory, then it is free for other containers usage. i.e. overcommit is natural and easy like on standalone Linux box when multiple applications compete for memory resources. |
| + | As a result simple container running ssh, apache, init and cron takes only 10-20Mb of physical RAM. Sure, for efficient caching of apache pages more RAM is needed. | ||
| − | # | + | # Containers memory management is system-wide wise. If one container needs more physical RAM (e.g. for apache pages caching) and hardware node have no more memory available, kernel will automatically reclaim last recently used caches of other containers. |
| + | |||
| + | # Parallels Virtuozzo containers product does a step further and introduces containers templates, which are used as a basis for all containers and special Copy-on-Write filesystem makes sure that original template is kept untouched and container gets its own private copy of template file when it tries to modify it. As a result all common files are shared across the containers and present on disk and in memory caches in a single instance. This saves memory, reduces I/O and makes L2/L3 caches work more effective. | ||
| + | |||
| + | == Why Virtual Machines are not that good? == | ||
| + | |||
| + | Hypervisors (Xen, ESX, KVM) are not that good on high density scenarios. There are multiple reasons for that: | ||
| + | # Memory is basically reserved on the host on VM start. e.g. KVM and XEN by default reserve whole memory and do not allow memory overcommitment. As a result you can't run more then 15 VMs with 1GB RAM on 16Gb box. ESX as the most advanced hypervisor uses page sharing and ballooning technologies to introduce memory overcommitment. However, on practice it allows to get only about 2x times overcommitment on the guests of the same type. From our experiments half of this improvement is due to page sharing and half due to ballooning. | ||
| + | |||
| + | # Multiple kernels and their system data structures in memory. | ||
| + | There are some technologies like RAM pages sharing and ballooning which help a bit. | ||
| − | |||
# what happens when CT is above it's limit | # what happens when CT is above it's limit | ||
# what happens when node RAM is exhausted | # what happens when node RAM is exhausted | ||
# plots and examples. Kir had http_load plot in the past. We will have LAMP results as well. | # plots and examples. Kir had http_load plot in the past. We will have LAMP results as well. | ||
Revision as of 18:36, 14 March 2011
Contents
Containers density. Why containers are so good at it?
What is density?
Density is a characteristics which tells one how many containers (CTs) or Virtual Machines (VMs) virtualization technology can run successfully on the given hardware. Typically users also care for quality of service of their software, i.e. how well their services are working on utilized node and how fast they respond to external requests. Average response time, 99.9% requests response time and max response time are typical metrics of quality of service. When hardware node is capable to bear the load these metrics either do not grow much with bigger number of containers or grow linearly. When hardware node becomes over utilized these metrics typically start to degrade exponentially (e.g. due to memory swap out).
What makes containers to be perfectly suitable for high density?
- Containers do not reserve memory assigned to it. They exhibit real-time elastic behavior, if applications do not use memory, then it is free for other containers usage. i.e. overcommit is natural and easy like on standalone Linux box when multiple applications compete for memory resources.
As a result simple container running ssh, apache, init and cron takes only 10-20Mb of physical RAM. Sure, for efficient caching of apache pages more RAM is needed.
- Containers memory management is system-wide wise. If one container needs more physical RAM (e.g. for apache pages caching) and hardware node have no more memory available, kernel will automatically reclaim last recently used caches of other containers.
- Parallels Virtuozzo containers product does a step further and introduces containers templates, which are used as a basis for all containers and special Copy-on-Write filesystem makes sure that original template is kept untouched and container gets its own private copy of template file when it tries to modify it. As a result all common files are shared across the containers and present on disk and in memory caches in a single instance. This saves memory, reduces I/O and makes L2/L3 caches work more effective.
Why Virtual Machines are not that good?
Hypervisors (Xen, ESX, KVM) are not that good on high density scenarios. There are multiple reasons for that:
- Memory is basically reserved on the host on VM start. e.g. KVM and XEN by default reserve whole memory and do not allow memory overcommitment. As a result you can't run more then 15 VMs with 1GB RAM on 16Gb box. ESX as the most advanced hypervisor uses page sharing and ballooning technologies to introduce memory overcommitment. However, on practice it allows to get only about 2x times overcommitment on the guests of the same type. From our experiments half of this improvement is due to page sharing and half due to ballooning.
- Multiple kernels and their system data structures in memory.
There are some technologies like RAM pages sharing and ballooning which help a bit.
- what happens when CT is above it's limit
- what happens when node RAM is exhausted
- plots and examples. Kir had http_load plot in the past. We will have LAMP results as well.
