Memory issues with Virtuozzo/OpenVZ

Sadly I didn't kept any logs. But I will re-install OS and do the installation from scratch and save it in a log file. Hope to deal with this soon when I get some free time (examination period period in university is killing me!).

Now I really hate myself. I already started to install a fresh OS {face palm}

Here's my log files. Hope it helps somehow! I also added the "ps aux" output after the installation of Octopus finished (untouched).

I knew that OpenVZ didn't have the performance of Xen , but I've never heard of memory leaks before !

I reduced the APC size to half but that didn't change anything. I think the problem is the number of workers loaded for memcached and php-cgi --fpm. Here's a list of the processes consuming most ram :

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND

bind      1565  0.0  0.6  83068 12680 ?        Ssl  07:03   0:00 /usr/sbin/named -u bind
mysql     1904  0.4  4.4 1140148 92496 ?       Sl   07:03   3:10 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib
root     36365  0.0  0.0  88188  1240 ?        Ss   17:36   0:00 nginx: master process /usr/sbin/nginx -c /
www-data 36366  0.0  0.1  88992  2184 ?        S    17:36   0:00 nginx: worker process                   
www-data 36367  0.0  0.1  89152  2504 ?        S    17:36   0:00 nginx: worker process                   
www-data 36369  0.0  0.0  88188  1472 ?        S    17:36   0:00 nginx: cache manager process
root     17783  0.1  0.2 155124  4388 ?        Ss   16:56   0:04 /usr/local/bin/php-cgi --fpm --fpm-config
www-data 17784  0.0  1.1 163604 23648 ?        S    16:56   0:00 /usr/local/bin/php-cgi --fpm --fpm-config
www-data 17785  0.0  0.6 157212 14652 ?        S    16:56   0:00 /usr/local/bin/php-cgi --fpm --fpm-config
www-data 17786  0.0  0.6 156956 14392 ?        S    16:56   0:00 /usr/local/bin/php-cgi --fpm --fpm-config
www-data 17787  0.0  0.6 156956 14396 ?        S    16:56   0:00 /usr/local/bin/php-cgi --fpm --fpm-config
nobody   36026  0.0  0.0  44724   816 ?        Ssl  15:15   0:01 /usr/bin/memcached -u nobody -p 11211 -m 6
nobody   36033  0.0  0.0  43840   816 ?        Ssl  15:15   0:01 /usr/bin/memcached -u nobody -p 11212 -m 6
nobody   36040  0.0  0.0  43840   820 ?        Ssl  15:15   0:01 /usr/bin/memcached -u nobody -p 11213 -m 6
nobody   36047  0.0  0.0  43840   820 ?        Ssl  15:15   0:02 /usr/bin/memcached -u nobody -p 11214 -m 6
nobody   36054  0.0  0.0  43840   820 ?        Ssl  15:15   0:01 /usr/bin/memcached -u nobody -p 11215 -m 6
nobody   36059  0.0  0.0  43840   816 ?        Ssl  15:15   0:01 /usr/bin/memcached -u nobody -p 11216 -m 6
nobody   36063  0.0  0.0  43840   820 ?        Ssl  15:15   0:01 /usr/bin/memcached -u nobody -p 11217 -m 6
nobody   36075  0.0  0.0  43840   816 ?        Ssl  15:15   0:01 /usr/bin/memcached -u nobody -p 11218 -m 6

I reduced the nginx workers to 2 , but I have no idea how to reduce them for memcached and php-cgi --fpm . Any suggestions?

I think you should rename the issue name to "Memory issues with OpenVZ" to avoid the confusion for the readers.

Let me re-phrase this. Xen is more "isolated" than OpenVZ in terms of virtualization. The major difference comes from the way they allocate memory. So burstable ram in OpenVZ comes from "borrowing" memory from another slice. So this cannot guarantee the allocation (at any moment system can shutdown processes). So the biggest problem with burst ram is that in OpenVZ , it can kill your application while in Xen it will only slow down (in Xen virtual memory that you can allocate is almost unlimited if you have enough swap space configured).
I think that's the reason you mentioned that OpenVZ can cause critical issues.
However I cannot find a single source of information stating that OpenVZ is the worst choice for Drupal or the cause of memory leaks.
I will try to investigate this issue and if I find anything useful, I'll post it for the sake of other OpenVZ users.

I understand the fact that database driven applications will perform much better in Xen. But in my case performance isn't the issue. It's a memory hog problem and according to your assumption is related to kernel configuration. I'm trying to find similar situations but I can't relate to any of these.

Regarding overselling: That's a big myth with Xen vs. OpenVZ. It's just easier to oversell with OpenVZ than with Xen. For Xen you need to apply a technique called ballooning. A special Linux kernel driver is installed on your system (balloon driver). When the Xen server/hypervisor needs more memory, and wishes to claim some from the guest VPS (domU), it asks the guest VPS’s balloon driver to inflate itself by asking its Linux kernel for some memory. Kernel memory allocation will be requested from the available memory for that VPS, and cannot be paged out to swap. Once the balloon driver consumes the memory, it then passes to dom0/hypervisor to be used elsewhere. So the amount of your VPS’s “total memory” will stay the same, but there will be a big increase in “used memory”, as a big chunk has now been used by the balloon driver inside the kernel, and possibly now a part of another VPS. The XEN balloon driver option has been available since version 3.3.
So Xen regarding memory , is not as "isolated" as people tend to think of. Overselling is something that can happen to both platforms.

I believe you should start by taking Kloxo out of the equation unless you really need to use it(and always with lowmem.flag) Generally, Kloxo is a memory hog and performance is mediocre.

more decriptive