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
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. >
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)
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)
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)
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
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.
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)
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 <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)
RSS Feed23 | |
|---|---|
23 | |
24 | |
22 | |
36 | |
23 | |
42 | |
29 | |
72 | |
29 | |
49 | |
41 | |
56 | |
64 | |
113 | |
31 | |
46 | |
39 | |
83 | |
55 | |
40 | |
66 | |
8 | |
33 | |
75 | |
30 | |
33 | |
17 | |
21 | |
37 | |
41 | |
11 | |
52 | |
46 | |
122 | |
76 | |
48 | |
88 | |
67 | |
61 | |
86 | |
53 | |
57 | |
22 | |
45 | |
47 | |
42 | |
50 | |
28 | |
25 | |
58 | |
53 | |
130 | |
92 | |
94 | |
35 | |
93 | |
95 | |
65 | |
70 | |
107 | |
41 | |
68 | |
81 | |
104 | |
208 | |
85 | |
80 | |
92 | |
62 | |
51 | |
54 | |
98 | |
95 | |
147 | |
56 | |
55 | |
77 | |
50 | |
47 | |
23 | |
43 | |
15 | |
39 | |
62 | |
19 | |
66 | |
36 | |
3 | |
8 | |
18 | |
1 |
