core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 255607
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 255607
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
У вас openvz с плохо настроенными лимитами на память. http://habrahabr.ru/post/53236/ вот здесь писали про нечто похожее (хотя и не совсем верно - там система управления памятью намного сложнее, чем просто ограничение виртуальной памяти). Смотрите в /proc/user_beancounters - там, скорее всего, заканчивается какой-нибудь kmemsize.
Выход - переезжать на KVM/Xen или искать хостера с нормально настроенными лимитами на память, например вот такими - http://hastebin.com/doyuhesosu (здесь лимиты выставлены через physpages и lockedpages, что тоже далеко от идеала с точки зрения гостевой ОС, но хотя бы даёт честный гигабайт памяти (после которого, впрочем, всё равно будет cannot fork).
А у Вас система 32-разрядная или 64? Если 32, то это может быть Low memory starvation.
Напишу лучше отдельным ответом, ибо в обсуждении оно там в убитом формате получилось:
rsync -avzP --numeirc-ids / root@newserver:/chroot --exclude=/proc/* --exclude=/sys/* --exclude=/dev/*
# for chroot
proc /chroot/proc proc rw,relatime 0 0
sysfs /chroot/sys sysfs rw,relatime 0 0
udev /chroot/dev devtmpfs rw,relatime,size=10240k,nr_inodes=4112034,mode=755 0 0
devpts /chroot/dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0