LXC speed

SamTzu

Renowned Member
Mar 27, 2009
529
17
83
Helsinki, Finland
sami.mattila.eu
Past 2 weeks we have been experiencing problems with KVM based high load website VM (thousands of concurrent users) and decided to move to LXC. I have to say the difference is like night and day. Say what you want about LXC and it's shortcomings (which are many) but it is fast. I'm glad the snapshots finally work. Now if only we could get live-migration and flat-file support and I would be a happy camper.
 
You just have to consider the different use cases. LXC has much less overhead, but is therefore tied more strongly into the host system. It'll never be 100% separated from the host, _some_ information will always be either directly or indirectly accessible. (Eg. even if /proc/cpuinfo would only show 4 of 48 cores, sched_getaffinity(2) will give you a bitmask telling you're running on cores 36, 40, 42 and 44 if that's where you're scheduled on. Unless someone was to go and add some more namespaces, like a CPU & scheduling namespace...)

As for live migration... it'll probably never be as stable and reliable™ as KVM... then again... windows+virtio+live migration isn't exactly reliable either. But who uses windows anyway ;-)
CRIU has to handle "a lot" - pretty much everything you can do in a process - while in a VM you have RAM and some driver states to copy... (bit of an understatement, but so is "a lot" ;-) ).

As for flat file support... I'm not exactly sure what you mean. You can ditch the ext4 image file if you put the container on ZFS where it'll be a subvolume. Alternatively you can use size=0, but then there's no size limit, and whether that's an option for you depends on what you're running in it.