@fomistoklus да просто за сегодня уже третий, наверное, ответ от меня, который заключался в переводе заголовка вопроса на аглицкий и кнопки "мне повезет" в гугле
@opium было бы странным, если бы график хостера показывал незанятую память, а у человека было бы "ааа, у меня памяти нет!". Хостеру пришлось бы чинить такое поведение. Повторюсь - проблема в некорректной работе с памятью. Система думает, что у неё ещё есть память (физическая), но по факту при попытке аллоцировать память ядро хостера говорит гостевой системе "иди в жопу, ты своё скушала". При том, что гостевая система всё равно не осознаёт, что памяти нет и продолжает глупые попытки аллоцировать ещё. И, само собой, не высвобождает память под новые процессы, так как считает, что у неё ещё дохрена памяти.
Работа с памятью в KVM/Xen выглядит по-другому. Системе говорят "на тебе одну плашку физической памяти на гигабайт и разбирайся сама". В этом случае гостевая система способна корректно работать с памятью, освобождать её вовремя, аллоцировать те самые петабайты. Но, если придти и шаловливыми ручками ограничить процесс виртуалки на 512 мегабайт в dom0-системе (а виртуалка продолжит думать, что у неё гигабайт, как написано в конфиге гипервизора) - то будут те же cannot fork, когда машина упрется в реально занятые 512 памяти.
Простой вам пример для сравнения. К Вам приходят и говорят - держи миллион долларов и трать на что хочешь. Покупаешь квартиру, подписываешь договор. И тут вдруг врываются дяди с автоматами и укладывают тебя спать. Оказывается, что на жильё из них ты можешь потратить только 5% (пресловутый kmemsize, критичный при форке). Вот примерно тоже самое в данной ситуации и происходит.
Не за что.
Включите, кстати, swap там небольшой, на 128 мегабайт, например - это сильно облегчит машине логику работы с памятью. Не добавит 128 мегабайт памяти, но даст ядру некоторую "свободу действий". mydebianblog.blogspot.ru/2010/05/swap-swap-linux.html как-то так.
Сильно много тоже не нужно, чтобы система в swap не уходила. А вот возможность переложить пару мегабайт на диск в случае ахтунга - может когда-нибудь выручить =)
@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 отвечать, если памяти не будет. Но падать она никуда не соберется.
@rusbaron а права у пользователя есть на это, которым подключаетесь? Я точно не уверен, как оно там включается. В каком-нибудь core edition такая возможность вообще выпилена может быть.
@rusbaron в опциях подключения к серверу поставьте галку "общая папка" и выберите каталог. При коннекте оно в проводнике на сервере появится (в виде диска Х или около того). Ну а там дальше как обычно)
@26info я вам ссылку вам дал на доку о том, как добавлять домены через api.
И не все регистраторы позволяют делегировать домен на те NS-ы, где нет записей о домене (точнее, очень мало их позволяет такое делать).
Так что:
1) api.yandex.ru/pdd/doc/reference/domain-control_reg...
2) делегируем
3) дожидаемся подтверждения
4) вносим записи
@26info смысл в подтверждении домена запросом через апи? добавили любой домен, "мамой клянусь, мой домен!" - и вам сразу разрешили им управлять. Так получается?
confirm_domain - факт его делегирования на dns1/2. Через апи для регистраторов можно получать подтверждение привязки домена к аккаунту через callback url, после чего начинать вносить записи.
@26info а откуда pdd "узнает", что новый делегированный домен на dns1/2 нужно привязать именно к вашему аккаунту, а не к моему, если никто из нас его себе не добавлял?
https://www.google.ru/search?q=DameWare&oq=DameWar... - оно вот тут обитает, вместо с пачкой утилит, которые полезны в подобных случаях.