Gregor Mosheh | 3 Jan 19:49 2008

a simple utility to execute something on all VEs

http://wiki.openvz.org/ExecuteInAllVEs

Simple but useful. If anybody has further enhancements, that'd be spiffy.

--

-- 
Gregor Mosheh / Greg Allensworth
System Administrator, HostGIS cartographic development & hosting services
http://www.HostGIS.com/

"Remember that no one cares if you can back up,
  only if you can restore." - AMANDA
Thorsten Schifferdecker | 3 Jan 23:40 2008

Re: a simple utility to execute something on all VEs

Hi Gregor,

i suggest to use vzlist, insteed looking to /etc/vz/conf, so only 
command will execute on running ve's and it's you dont like execute 
command on VE 0, there's a 0.conf in /etc/vz/conf, too ;-)

# for veid in `vzlist -Hoveid`; do vzctl exec $veid <command>; done

Bye,
  Thorsten

Gregor Mosheh wrote:
> http://wiki.openvz.org/ExecuteInAllVEs
> 
> Simple but useful. If anybody has further enhancements, that'd be spiffy.
> 
Jeff Blasius | 4 Jan 19:36 2008
Picon

Re: Re: Memory calculations

Hello Vaverin,
Yes, believe me, I've read the documentation and it's generally very
good. But, for this particular point I just don't follow it. Maybe
it's just me.

So, man vzcalc says little more than: (resourses should be resources btw)
Promised - shows the resourses soft limit values "promised" for a given VE.
Max - shows the resourses hard limit values "promised" for a given VE.

This basically just redefines the terms promised and max, but doesn't
relate them to openvz beancounters in any way. From my numbers it
appears that
Promised = PRIVVMPAGES * 4096 / Ram + Swap
and
Max = (PRIVVMPAGES * 4096 / Ram + Swap) + Num. Proc

Assuming Num. Proc relates to the beancounter numproc,
Num. Proc = Num. of processes within the VE / 16000 (from
http://wiki.openvz.org/Numproc#numproc)
Is this correct?

I think my problems with the above are two things.
1. I'm not certain where max comes from and if it does come from the
above inferred formulas why it's really useful. I mean it's the
maximum of two seemingly independent beancounters. and
2. Promised seems like a misleading word (if in fact it does relate to
PRIVVMPAGES) since VMGUARPAGES is actually the "allocation guarantee".

Thanks,
                 jeff
(Continue reading)

Chris Turan | 6 Jan 05:40 2008

Re: Patch to turn a centos-4 metadata into a centos-5 version

Has anyone had any luck with template I provided earlier?  A copy of my 
earlier e-mail is below.

-Chris

Chris Turan wrote:
> I've recently put together this patch to convert a vanilla centos-4 
> metadata into one for centos-5.  Template works flawlessly for me.
> 
> Instructions to apply the patch:
> 1) wget 
> http://download.openvz.org/template/metadata/centos-4/src/vztmpl-centos-4.src.tar.bz2 
> 
> 2) tar xvjf vztmpl-centos-4.src.tar.bz2
> 3) cd centos-4
> 4) patch -p1 < /path/to/attached/centos-5-metadata.diff
> 5) yum install createrepo
> 6) make clean
> 7) make rpms
> 
> If your arch is i386, the metadata rpm should now be located in:
> /usr/src/redhat/RPMS/i386/vztmpl-centos-5-2.0-2.i386.rpm
> 
> 
> Notes:
> - "kernel = 2.6.18" is needed to fix the "Error: initscripts conflicts 
> with kernel < 2.6.12"
> - udevd must be disabled when the vps starts up
> 
> 
(Continue reading)

Max Deineko | 7 Jan 08:55 2008
Picon

TCP packets lost?

Hi,

I'm not really sure where to ask for help regarding my problem; I also
have posted to the apache group some time ago, but have not found a
solution.  If you think this is the wrong group, I apologize.  Also, any
hint as to where ask for help would be highly appreciated.

I'm facing following problem: Apache running inside an OpenVZ VPS,
serving multiple VirtualHosts.  Now, it has regular availabiliy
problems, which appears to be neither load nor request pattern related.

What I don't quite understand is this: during the periods when the
server isn't available (and seems to do nothing) most of TCP sessions
look like the one below - apache keeps resending the handshake SYNACK
packets to the client although client's response is clearly here
(tcpdump done from inside the VPS).

Now I would think that even when the Apache proccess would hang, or be
waiting for some other component, the TCP stack part of the application
(or the kernel, for that matter) would still behave normally - is this
wrong? I.e. is such behaviour normal?  Or do the incoming packets get
lost somewhere?

My first guess would have been that when the server is busy serving an
expensive request, the tcp rcv buffer would get full and packets would
get dropped.  But wouldn't tcpdump not be able to see them then?

Any help would be highly appreciated,

thanks -
(Continue reading)

Marcin Owsiany | 7 Jan 10:05 2008
Picon

Re: TCP packets lost?

On Mon, Jan 07, 2008 at 07:55:43AM +0000, Max Deineko wrote:
> My first guess would have been that when the server is busy serving an
> expensive request, the tcp rcv buffer would get full and packets would
> get dropped.  But wouldn't tcpdump not be able to see them then?
> 
> Any help would be highly appreciated,

http://forum.openvz.org/index.php?t=msg&goto=21592

My theory is that when the (receive buffer size / current connections)
is too small for the window size, then kernel gets itself into a state
where it's impossible to recover a connection.

--

-- 
Marcin Owsiany <marcin@...>              http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216

"Every program in development at MIT expands until it can read mail."
                                                              -- Unknown
Max Deineko | 7 Jan 11:01 2008
Picon

Re: TCP packets lost?

Marcin Owsiany <marcin@...> wrote:
> On Mon, Jan 07, 2008 at 07:55:43AM +0000, Max Deineko wrote:
>> My first guess would have been that when the server is busy serving an
>> expensive request, the tcp rcv buffer would get full and packets would
>> get dropped.  But wouldn't tcpdump not be able to see them then?

> http://forum.openvz.org/index.php?t=msg&goto=21592
>
> My theory is that when the (receive buffer size / current connections)
> is too small for the window size, then kernel gets itself into a state
> where it's impossible to recover a connection.

Thanks a lot.  I already had found the thread and tried increasing
tcp_rmem size, which hung the webserver completely (maybe it was a litte
too big ;), but I'm still experimenting with the settings.

Of course there might be a problem with other server components, and I'm
not really a networking expert, it's just that the tcp flow doesn't look
like what I'd expect it to.

So is the behaviour I see normal or is there really something wrong at
this level already?  Even if one assumed that userland components were
broken and went haywire sometimes?

Thanks, Max.
Vitaliy Gusev | 7 Jan 12:37 2008
Picon

Re: Re: TCP packets lost?

On 7 January 2008 13:01:24 Max Deineko wrote:
> Marcin Owsiany <marcin@...> wrote:
> > On Mon, Jan 07, 2008 at 07:55:43AM +0000, Max Deineko wrote:
> >> My first guess would have been that when the server is busy serving an
> >> expensive request, the tcp rcv buffer would get full and packets would
> >> get dropped.  But wouldn't tcpdump not be able to see them then?
> 
> > http://forum.openvz.org/index.php?t=msg&goto=21592
> >
> > My theory is that when the (receive buffer size / current connections)
> > is too small for the window size, then kernel gets itself into a state
> > where it's impossible to recover a connection.
> 
> Thanks a lot.  I already had found the thread and tried increasing
> tcp_rmem size, which hung the webserver completely (maybe it was a litte
> too big ;), but I'm still experimenting with the settings.
> 
> Of course there might be a problem with other server components, and I'm
> not really a networking expert, it's just that the tcp flow doesn't look
> like what I'd expect it to.

Please show files: /proc/net/netstat, /proc/net/snmp ( inside VE)

Have you seen any suspicious messages in dmesg related to this issue?

> 
> So is the behaviour I see normal or is there really something wrong at
> this level already?  Even if one assumed that userland components were
> broken and went haywire sometimes?
> 
(Continue reading)

Max Deineko | 7 Jan 13:02 2008
Picon

Re: TCP packets lost?

Vitaliy Gusev <vgusev@...> wrote:
> On 7 January 2008 13:01:24 Max Deineko wrote:
>> > On Mon, Jan 07, 2008 at 07:55:43AM +0000, Max Deineko wrote:
>> >> My first guess would have been that when the server is busy
>> >> serving an expensive request, the tcp rcv buffer would get full
>> >> and packets would get dropped.  But wouldn't tcpdump not be able
>> >> to see them then?

>> I already [...] tried increasing tcp_rmem size, which hung the
>> webserver completely (maybe it was a litte too big ;), but I'm still
>> experimenting with the settings.
>>
>> Of course there might be a problem with other server components, and
>> I'm not really a networking expert, it's just that the tcp flow
>> doesn't look like what I'd expect it to.

> Please show files: /proc/net/netstat, /proc/net/snmp ( inside VE)

See below.  Currently running with

  net.ipv4.tcp_rmem = 4096        87380   184762
  net.core.rmem_max = 184761

> Have you seen any suspicious messages in dmesg related to this issue?

Indeed, dmesg shows

  TCP: Treason uncloaked! Peer 91.4.192.15:52306/80 shrinks window 204385904:204399829. Repaired.
  TCP: Treason uncloaked! Peer 91.4.192.15:52306/80 shrinks window 204385904:204399829. Repaired.
  TCP: Treason uncloaked! Peer 91.4.192.15:52306/80 shrinks window 204385904:204399829. Repaired.
(Continue reading)

Max Deineko | 7 Jan 13:20 2008
Picon

Re: TCP packets lost?

Max Deineko <max@...> wrote:
> Vitaliy Gusev <vgusev@...> wrote:
>> On 7 January 2008 13:01:24 Max Deineko wrote:

>> Please show files: /proc/net/netstat, /proc/net/snmp ( inside VE)

Prettier:

/proc/net/snmp:

  Forwarding      2
  DefaultTTL      64
  InReceives      55086729
  InHdrErrors     0
  InAddrErrors    0
  ForwDatagrams   0
  InUnknownProtos 0
  InDiscards      0
  InDelivers      55079918
  OutRequests     59160345
  OutDiscards     0
  OutNoRoutes     0
  ReasmTimeout    22
  ReasmReqds      64
  ReasmOKs        0
  ReasmFails      22
  FragOKs         0
  FragFails       0
  FragCreates     0

(Continue reading)


Gmane