running with no limits? [message #30315] |
Wed, 21 May 2008 02:04  |
Steve Wray
Messages: 18 Registered: August 2007
|
Junior Member |
|
|
Hi there,
I have a server running OpenVZ with several VMs running on it.
At the moment I have to specify various limits to each VM configuration
and, when they hit their limits strange things can happen.
Ideally I'd let them all have full access to all the resources available
on the physical server. They can fight it out among themselves if they
want to compete for the resources. Most of these VMs are quiescent and
not actually doing much at all most of the time anyway.
I've not been able to figure out how to configure OpenVZ like this
though. Is it something I have to set in each VM config file? Or is it a
server-wide thing?
Any ideas?
Thanks!
|
|
|
|
|
|
Re: running with no limits? [message #31773 is a reply to message #31771] |
Wed, 09 July 2008 07:45   |
|
Let me suggest yet another way -- use config generated by vzsplit 1.
You'll have something very close to "unlimited" but without deficiency
#3 pointed to by Kirill.
Kirill Korotaev wrote:
> You just need to set maximum values to barrier/limits and VM will be essentially uinlimited.
> Check /proc/user_beancounters to see how host VM is limited with "unlimited" values (i.e. highest possible
> limit value).
>
> 3 notes:
> 1. max limit is different on x32 and x64 machines
> 2. both barrier and limit must be set to these values.
> 3. in such a configuration if a global memory shortage happens out-of-memory
> killer kills some app as in native Linux system.
>
> Thanks,
> Kirill
>
> Steve Wray wrote:
>
>> No answers? Its been a while...
>>
>> We have a bunch of openvz VMs, nothing 'in production'. The host has 4G
>> of RAM. I want all the VMs to have access to 4G of RAM and all the
>> sockets and other stuff that they may need at any time; I don't have
>> time to carefuly tune the parameters of all of them to just what they
>> need and no more.
>>
>> I don't mind or care that they are over-committed I just want them to
>> have max resources.
>>
>> Thanks
>>
>> Steve Wray wrote:
>>
>>> Hi there,
>>>
>>> I have a server running OpenVZ with several VMs running on it.
>>>
>>> At the moment I have to specify various limits to each VM
>>> configuration and, when they hit their limits strange things can happen.
>>>
>>> Ideally I'd let them all have full access to all the resources
>>> available on the physical server. They can fight it out among
>>> themselves if they want to compete for the resources. Most of these
>>> VMs are quiescent and not actually doing much at all most of the time
>>> anyway.
>>>
>>> I've not been able to figure out how to configure OpenVZ like this
>>> though. Is it something I have to set in each VM config file? Or is it
>>> a server-wide thing?
>>>
>>> Any ideas?
>>>
>>> Thanks!
|
|
|
Re: running with no limits? [message #31782 is a reply to message #31772] |
Wed, 09 July 2008 22:08  |
Steve Wray
Messages: 18 Registered: August 2007
|
Junior Member |
|
|
Benoit Branciard wrote:
> Steve Wray a écrit :
>> No answers? Its been a while...
>>
>> We have a bunch of openvz VMs, nothing 'in production'. The host has
>> 4G of RAM. I want all the VMs to have access to 4G of RAM and all the
>> sockets and other stuff that they may need at any time; I don't have
>> time to carefuly tune the parameters of all of them to just what they
>> need and no more.
>>
>> I don't mind or care that they are over-committed I just want them to
>> have max resources.
>>
>
> vzsplit -n 1 -f max-limits
>
> then for each container NNN:
> vzctl set NNN --applyconfig max-limits --save
Fantastic, thanks guys.
The thing is that almost all of the time almost all of these VMs will be
unused. But when they are used they can use a lot of resources.
However, stopping and starting them as they are needed isn't an option.
I need to have them all running at all times.
Unfortunately, the applications running on them can behave quite
mysteriously when things like tcpsndbuf hit a limit.
And I've seen some very very strange behavior out of applications when
these limits get hit... its been truly baffling sometimes!
|
|
|