On 10/03/2013 07:26 AM, Mark J. wrote:
On Wed, Oct 02, 2013 at 03:47:48PM -0700, Kir Kolyshkin wrote:
On 10/02/2013 12:07 PM, Mark J. wrote:
On Wed, Oct 02, 2013 at 11:48:02AM -0700, Kir Kolyshkin wrote:
I suggest you to just put * as parent name then.
Will give that a try now that I have the other info you asked for below:
This is 2G RAM. I haven't seen your my.cnf, but 2G is pretty generous,
I am not really sure mysqld hits this, or is it a global memory shortage.
Show me your /proc/user_beancounters or, yet better, vzubc output --
after mysql is killed -- to find out. We are interested in
failcnt/FAIL column.
Here is the ubc info from right after a mysql oom kill:
root@ssdman5 ~ #vzubc 3679
----------------------------------------------------------------
CT 3679 | HELD Bar% Lim%| MAXH Bar% Lim%| BAR | LIM | FAIL
-------------+---------------+---------------+-----+-----+------
kmemsize|41.3M - - | 283M - - | - | - | -
lockedpages|15.5M - - |33.5M - - | - | - | -
privvmpages|3.07G - - |18.2G - - | - | - | -
shmpages|4.15M - - |4.15M - - | - | - | -
numproc| 246 - - | 417 - - | - | - | -
physpages| 669M - 32%| 2G - 100%| - | 2G| 1.37K
vmguarpages| - - - | - - - | - | - | -
oomguarpages| 702M - - |2.36G - - | - | - | 226
numtcpsock| 74 - - | 158 - - | - | - | -
numflock| 9 - - | 20 - - | - | - | -
numpty| - - - | 2 - - | - | - | -
numsiginfo| 6 - - | 36 - - | - | - | -
tcpsndbuf| 2.2M - - |6.83M - - | - | - | -
tcprcvbuf|1.16M - - |2.52M - - | - | - | -
othersockbuf| 629K - - |4.32M - - | - | - | -
dgramrcvbuf| - - - |88.1K - - | - | - | -
numothersock| 104 - - | 290 - - | - | - | -
dcachesize|21.4M 4% 4%| 266M 52% 52%| 512M| 512M| -
numfile|1.77K - - |8.87K - - | - | - | -
numiptent| 286 - - | 286 - - | - | - | -
swappages| 105M - 20%| 512M - 100%| - | 512M| 5.79M
----------------------------------------------------------------
As you can see, there are both ram (physpages) and swap fails.
There is nothing wrong with the current behaviour -- if all RAM
and swap is gone, there is absolutely no other way than to kill
some process.
So OOM killer configuration won't help here, you need to either
decrease mysql appetites (/etc/my.cnf) or increase RAM or swap.
Apparently my.cfg is not configured for a system with 2G of RAM
(if you can show my.cnf we can see where it needs to be tuned),
and this is the source of the problem and this is what needs to be
fixed. It would be the same way on a real physical server, i.e.
the problem is orthogonal to OpenVZ.
But the easiest way would be to increase swap for this container,
and then check if swap failcounter is not increasing. If there will
be enough ram+swap, there will be no OOM kills.
Also, I wonder how much RAM do you have on your server, and how
many such containers do you run on it?
Nodes have 32G on them, this particular node only allows up to 40 vm's due to
the cPanel vm's having either 2, 3, or 4G depending on the plan.
This is severe oversell -- you have 32G but sell that as 80 to 160G.
At the very least you have to have an adequate amount of swap
on the node -- so that RAM+swap on the node should be more
than sum of all RAM and SWAP for all containers. Currently there
is no tool for that, but it's pretty easy to write such a script.
_______________________________________________
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
