Re: LuaJIT-on-Xen?
- From: Alexander Gladysh <agladysh@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Sun, 5 May 2013 17:21:47 +0400
On Sun, May 5, 2013 at 4:46 PM, Justin Cormack
<justin@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Sun, May 5, 2013 at 1:00 PM, Alexander Gladysh <agladysh@xxxxxxxxx> wrote:
>> I mean that we were *not* happy with the level of isolation that
>> OpenVZ provided (several years ago).
>>
>> Are there any texts documenting experience with LXC under high load
>> scenarios? I'm especially interested in rationing HDD between several
>> VMs (containers?), including a few very aggressive HDD users.
>>
>> In our experience, this is somewhat problematic even for Xen (but it
>> is possible that we don't wield it good enough).
>
> Seriously just get SSD. You cannot expect to ration 100iops sanely
> between multiple processes and get anything much useful for aggressive
> users. Suspect you have marginally more control under lxc as all the
> requests are seen by the same kernel. You end up with pretty much the
> same tools, or you can customise the elevator. But an SSD is much more
> useful.
The point is to avoid degradation of performance for non-aggressive
users if aggressive ones get carried away. (Just in case: by user here
and above I meant a VM.)
If aggressive users do get carried away, they are to be fixed and
optimized. But this is not instantaneous. Meanwhile rest of the system
should work (possibly in a gracefully degraded mode). Otherwise
virtual cluster tends to "blow up" with unpleasant consequences.
>>> in fact, this project would be almost trivial with LXC, since a
>>> container starts with an arbitrary process that becomes the root of
>>> the subtee, and looks like PID#1 "from inside". if that process is
>>> "init", and you give it a full installation in the chroot, then you
>>> have a new OS in a VM. if it's any other proces (say, a LuaJIT
>>> worker!) then it's a lot simpler, like a better chroot
>>
>> Well, yes. But will the isolation be good enough?
>
> Security isolation or performance?
Performance first, but security is important as well.
>> We hit many kinds of pitfalls with Xen (and with OpenVZ earlier), so
>> I'm wary about adopting yet another virtualization scheme... That
>> being said, we're already using LXC at a very basic level (mostly in
>> development / testing scenarios where we need to emulate Xen cluster
>> without paying the full cost), and plan to use it more, so it is not
>> *that* alien and unknown. :-)
>>
>
> Linux containers are not really a virtualisation scheme per se, it is
> a set of kernel tools for process resource control (namespaces,
> cgroups) which the lxc project dresses up like virtualisation, but it
> is better to consider it a toolset.
OK, makes sense.
Thanks,
Alexander.
Other related posts:
