|
|
|
|
|
|
|
|
|
|
|
Re: OpenVZ IO Isolation ? [message #43383 is a reply to message #43381] |
Fri, 02 September 2011 18:06 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
seanfulton
Messages: 105 Registered: May 2007
|
Senior Member |
|
|
I think the VZ containers should prevent activity inside one container from stopping IO on all other containers. Otherwise, what is the point of containers? For that matter, if the Linux OS can't prevent one task from robbing IO from all other tasks on the system, what is the point of a multi-tasking, multi-user OS?
I think this is a defect, and am not sure why people are so quick to say it is normal Linux or OpenVZ behavior.
Again, the purpose of a multitasking OS to *share* resources. The purpose of OpenVZ is to *share* a server. If a normal, non-privileged user inside one container can launch a non-privileged task that blocks all IO from other containers, including the HN, I think that is a defect.
I have done a bit of research on this and it appears to be a bug in the 2.6.18 kernel source, likely in the x86_64 branch. I've seen many reports from non-OpenVZ users who have problems like this but they seem to resolve themselves through driver updates, firmware updates to the RAID subsystem they are using, etc. Users who are not using a RAID subsystem seem to continue to have the problem. But all of them start with the 2.6.18 kernel, x86_64 version.
Also, this is not a problem in the RHEL6 releases. I have tested by moving a VE from a RHEL5 machine where the problem is demonstrated to a RHEL6 machine and the problem goes away.
sean
|
|
|
|
Re: OpenVZ IO Isolation ? [message #43386 is a reply to message #43384] |
Fri, 02 September 2011 20:37 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
mustardman
Messages: 91 Registered: October 2009
|
Member |
|
|
Defect or not, why not try set the offending container to ioprio 3 and/or the other containers to ioprio 5 and see what happens.
I'm kind of surprised you have not tried this yet. I'm not saying it will solve your problem. I'm just saying that it wouldn't hurt to try even if you don't think you should have to do that under normal circumstances.
I have had some I/O problems in the past when certain containers are doing certain things and ioprio has helped me. Saying you don't have that problem under RHEL6 is not conclusive imho. There could be other reasons for that.
[Updated on: Fri, 02 September 2011 20:49] Report message to a moderator
|
|
|
|
|