Hello,<br><br>1. Looks like new OpenVZ suspend/resume feature doesn't work for a CT that contains running Oracle DB.<br><br>Resume always trigger kill-everything cycle and then CT dies. <br>Although I had no any issues with container before suspend (all user beancounters are zeroes and <br>
nothing in logs).<br><br>HN and CT are both 6.3 with latest yum updates.<br>Kernel: 2.6.32-042stab063.2.<br>Oracle 11.2.0.3.<br><br>Here's what I have in HN /var/log/messages after vzctl resume 908:<br><blockquote style="margin:0px 0px 0px 6.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<font size="1">Nov 19 22:35:31 kernel: [24961.760236] CT: 908: started<br>Nov 19 22:39:19 kernel: [25189.757112] >>> 908 oom generation 0 starts<br>Nov 19 22:39:19 kernel: [25189.757120] __ratelimit: 4 callbacks suppressed<br>
Nov 19 22:39:19 kernel: [25189.757125] 41252 (crond) invoked loc oom-killer: gfp 0x200d2 order 0 oomkilladj=0<br>Nov 19 22:39:19 kernel: [25189.757135] UB-908-Mem-Info:<br>Nov 19 22:39:19 kernel: [25189.757139] Node 0 DMA scan:0 a_anon:0 i_anon:0 a_file:0 i_file:0 unevictable:0<br>
Nov 19 22:39:19 kernel: [25189.757145] Node 0 DMA32 scan:5804378 a_anon:233525 i_anon:77815 a_file:0 i_file:0 unevictable:0<br>Nov 19 22:39:19 kernel: [25189.757152] Total 311339 anon:311339 file:0 a_anon:233514 i_anon:77825 a_file:0 i_file:0 unevictable:0<br>
Nov 19 22:39:19 kernel: [25189.757157] RAM: 315097 / 307200 [1] SWAP: 21285 / 230400 [0] KMEM: 13336576 / inf [0] DCSZ: 680503 / inf [0] OOMG: 0 / inf [0] Dirty 0 Wback 0 Dche 31 Prnd 0<br>Nov 19 22:39:19 kernel: [25189.757272] Out of memory in UB: Kill process 41261 (oracle) score 3 or sacrifice child<br>
Nov 19 22:39:19 kernel: [25189.757305] OOM killed process 41261 (oracle) vm:950828kB, rss:0kB, swap:8364kB<br>Nov 19 22:39:20 kernel: [25189.818729] OOM killed process oracle (pid=41261, ve=908) exited, free=129959.<br>Nov 19 22:39:20 kernel: [25189.818736] UB-908-Mem-Info:<br>
Nov 19 22:39:20 kernel: [25189.818741] Node 0 DMA scan:0 a_anon:0 i_anon:0 a_file:0 i_file:0 unevictable:0<br>Nov 19 22:39:20 kernel: [25189.818747] Node 0 DMA32 scan:6025211 a_anon:233532 i_anon:77815 a_file:0 i_file:0 unevictable:0<br>
Nov 19 22:39:20 kernel: [25189.818754] Total 311334 anon:311334 file:0 a_anon:233514 i_anon:77820 a_file:0 i_file:0 unevictable:0<br>Nov 19 22:39:20 kernel: [25189.818759] RAM: 315062 / 307200 [6] SWAP: 19350 / 230400 [0] KMEM: 13193216 / inf [0] DCSZ: 680503 / inf [0] OOMG: 0 / inf </font><br>
</blockquote><div>(full version is attached).<br><br>/etc/vz/conf/908.conf :<br><blockquote style="margin:0px 0px 0px 6.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><font size="1">ONBOOT="yes"<br>
BOOTORDER="350"<br>CPUUNITS="250"<br>IOPRIO="5"<br><br>PHYSPAGES="0:1300M"<br>SWAPPAGES="0:1000M"<br><br>DISK_QUOTA="yes"<br>DISKSPACE="22G:25G"<br>DISKINODES="900000:1100000"<br>
QUOTATIME="0"<br><br>VE_ROOT="/vz/root/$VEID"<br>VE_PRIVATE="/vz/private/$VEID"<br>OSTEMPLATE="centos-6-x86_64-CT5<font size="1">xx</font>"<br>ORIGIN_SAMPLE="vswap-1g"<br>
IP_ADDRESS="172.9.<font size="1">x</font>.<font size="1">x</font>"<br>HOSTNAME="ora<font size="1">xx</font>"<br></font></blockquote><br>and then a bunch of parameters taken from <a href="http://wiki.openvz.org/Oracle_10g_VE">http://wiki.openvz.org/Oracle_10g_VE</a><br>
all equal to "unlimited". All except PHYSPAGES that is shown above.<br><br>I did this a few times - decreased amount of memory that Oracle consumes, it is a consistent bug,<br>or obviously I don't understand something. Also wanted to notice that every time I suspended CT,<br>
the dump file was around 1.3Gb even after I decreased amount of memory assigned to Oracle by 300M.<br>Does OpenVZ dump what PHYSPAGES says? I was surprised by this - my expectation was it'll dump <br>only memory pages that are in use/allocated.<br>
<br><br>2. Is any way to disable automatic suspend/resume - I read that HN reboot causes all CTs to suspend,<br> and when it boots up they got resumed. I don't want this behavior for Oracle CT now.<br><br><br>Best regards,<br>
<br>Ruslan<br><br></div>