Из-за чего повышенное потребление памяти на VPS?

Чем они не корректные, человек купил 512мб с бёрстом до гига, гиг выжрал и система не дает ему памяти. Все так о должно работать. И почему вы считаете купив гиг оперативы на том де дигиталокеане он будет выдавать больше гига?

@opium
Человек купил 512мб хуй пойми чего, а не физической RAM. По другому я здесь выразиться не могу.
Linux работает с памятью очень правильно и красиво - с одной стороны стремиться занять всю доступную память (хотя бы даже page-кэшом или как dirty-pages). С другой стороны, ситуация, когда форку приложения нельзя выделить память означает следующее:
- у системы нечего переложить в swap (или его вообще нет).
- у системы нечего выгрузить (вся память ушла в kmem или в активные процессы в состоянии R).
- у системы нет свободного мегабайта памяти на то, чтобы сделать форк (а именно столько физической памяти нужно для форка примерно любого процесса, из-за особенностей его реализации). Оно, конечно, могло бы потом прибиться OOM-ом или сразу в swap уйти, но форкнуться ему бы ядро дало.

Из чего можно сделать 2 вывода:
1) хостер некорректно считает память (например, считает т.н. виртуальную память, которой для форка php нужно действительно мегабайт 200). При том, что в случае нормальной работы ядра (на физической машине, внутри KVM, в openvz с vswap и корректными лимитами) можно сделать allocate на несколько петабайт памяти (или сколько там позволяет 64-битная архитектура) и вам за это ничего не будет, кроме места, которое в памяти займёт указание на allocate. Грубо говоря, ядро хостера вместо подсчета памяти для виртуалки просто складывает одно из значений занятой памяти (RSS или VIRT, если совсем не повезло) для всех её процессов. При том, что и RSS, и VIRT не имеют никакого отношения к реальному потреблению "железной" памяти. И даже математика с применением SHR не поможет.
2) у хостера стоит низкий лимит на какую-то из крутилок в openvz. Наиболее популярные - kmemsize ("пиздец апачу") и tcpsockets ("пиздец всем приложения, работающим с сетью").

И да. Всё это сделано на основе фразы "сервак падал" и 5 лет ковыряния с разными системами виртуализации - OOM разнесет всю машину в клочья, но она будет пинговаться и по ssh отвечать, если памяти не будет. Но падать она никуда не соберется.

Человек пишет что он смотрит мониторинг загрузки памяти и крашится у него процесс только когда заполняется гиг памяти.

@opium было бы странным, если бы график хостера показывал незанятую память, а у человека было бы "ааа, у меня памяти нет!". Хостеру пришлось бы чинить такое поведение. Повторюсь - проблема в некорректной работе с памятью. Система думает, что у неё ещё есть память (физическая), но по факту при попытке аллоцировать память ядро хостера говорит гостевой системе "иди в жопу, ты своё скушала". При том, что гостевая система всё равно не осознаёт, что памяти нет и продолжает глупые попытки аллоцировать ещё. И, само собой, не высвобождает память под новые процессы, так как считает, что у неё ещё дохрена памяти.

Работа с памятью в KVM/Xen выглядит по-другому. Системе говорят "на тебе одну плашку физической памяти на гигабайт и разбирайся сама". В этом случае гостевая система способна корректно работать с памятью, освобождать её вовремя, аллоцировать те самые петабайты. Но, если придти и шаловливыми ручками ограничить процесс виртуалки на 512 мегабайт в dom0-системе (а виртуалка продолжит думать, что у неё гигабайт, как написано в конфиге гипервизора) - то будут те же cannot fork, когда машина упрется в реально занятые 512 памяти.

Простой вам пример для сравнения. К Вам приходят и говорят - держи миллион долларов и трать на что хочешь. Покупаешь квартиру, подписываешь договор. И тут вдруг врываются дяди с автоматами и укладывают тебя спать. Оказывается, что на жильё из них ты можешь потратить только 5% (пресловутый kmemsize, критичный при форке). Вот примерно тоже самое в данной ситуации и происходит.