память на VDS

Я вам уже писал что вы не умеете их готовить, запустится, даже более-менее будет работать..

Не на Xen конечно, на этой технологии с 64Мб ОЗУ разве что IRC ставить, да VPN юзать.

- а к чему тогда гневная филиппика про оверселл? Дано: в настройках PHP - 64Мб лимит ОП, на аккаунте гарантированный минимум 64Мб ОП, вопрос - откуда возьмется память для Apache, MySQL, еще пары процессов PHP? Может надо сказать: "сим-салабим" и "трах-тибидох"? И тогда память чудесным образом появится? Либо надо держать сервер полупустым (во что никогда не поверю), либо оверселл, оверселл, оверселл :D

- ну слава богу, а то кто-то недавно обещал меня научить запускать Xen VPS на 64 Мб 😎 (это был Павел Гаврилин, правда он отказался учить задаром)

Перечитываем и пишем опровержение >>> ;)

Видимо на ваших "честных" VDS и бывает оверселл при ГАРАНТИРОВАННЫХ параметрах, на то видимо и кавычки в вашем написании.

Не верите - ваше дело, есть несколько клиентов на старых тарифах с 64Мб ОЗУ.

Откорректированные настройки ОС, правильно настроенный LAMP, 7 активных подключений и еще остается 10Мб ОЗУ.

DLag добавил 12.05.2009 в 20:54

В аптеках таблетки для памяти продаются, говорят помогает...

P.S.: Можем поспорить на n-ю суму денег что настрою такую сборку и она будет работать. Но я думаю что вы скажите что не спорите...

- запутали Вы с DLag меня окончательно! 😕 Помню что кто-то обещал за деньги научить Xen на 64Мб запускать, да чтоб работало, чтоб сайты на PHP руду давали ... А кто обещал? И обещал ли? Теперь не разберу 🙄 Приношу извинения, если кого не по делу задел 🍻

Brim.ru добавил 12.05.2009 в 21:02

- да ну Вас, у нас (при использовании Xen) и слова то такого: "ГАРАНТИРОВАННЫХ" - не знают, так как других и не бывает ;)

- ну вот опять ... не пойму о чем идет речь? Обещают за деньги показать нормально работающий Xen VPS с LAMP на 64Мб? Или о чем вообще речь?

Если отойти от темы взаимных оскорблений, то немного задела следующая фраза:

>Как можно убить ноды, когда мы продаем ровно столько ресурсов, сколько можем? Если мы продаем 10 пользователям по одной десятой сервера, в сумме получается 1 сервер. Как его можно этим убить?

Сервер - это не только процессор и память. Например, я думаю, что тут не была учтена нагрузка на дисковую подсистему, а у XEN она больше, чем у *vz, так как он оперирует не с файлами, а с устройствами. Особенно плохо придется, когда впски начнут свопиться на свои виртуальные диски.

Кроме того, на виртуализацию так же существуют свои накладные ресурсы. Незначительные, но существуют.

- чтобы такой проблемы на возникало, надо:

1. Не делать VPS c маленьким количеством ОП! IMHO, 128 Мб это тот минимум который позволяет Xen VPS работать без свопирования, но который нельзя использовать под мало мальски нагруженные сайты. А уж разговоры про 64Мб у меня постоянно вызывают, мягко выражаясь, недоумение и сомнение.

2. Как говорил тут кое-кто, "надо уметь их готовить" 😎 (я имею в виду свопы - кто в теме поймет, кто не в теме, тому и знать не к чему)

3. Если будет "плохо" это станет ясно сразу, а не когда жадный хостер забьет весь сервер аккаунтами по 64Мб. Если будет "хорошо", то ничего не изменится, даже если хостер забьет весь сервер аккаунтами. В этом плане Xen-виртуализация (с учетом правильного создания хостером свопов) существенно более предсказуема, в отличие от OpenVZ, где проблемы с диском также могут возникнуть при увеличении количества аккаунтов, а вот память на аккаунтах по 64Мб может исчезнуть совершенно неожиданно и как тогда будет работать софт, на гарантированных 64Мб, остается только гадать (а потом клиенты начинают рассказывать байки - был хороший хостер, да испортился, сначала летало все, а теперь еле ползает).

1. В принципе, согласен. Но под что-то простое и 64 хватит (например, bind под вторичный сервер, nginx чтобы отдавать статику на пару тысяч парковочных доменом, под ту же самую почту). Важно понимать, что для каждого случая - свой тариф.

2. Увы, мой опыт работы с XEN нулевой, знаю только теорию. Если не сложно, поясните.

3. А почему? Ведь когда 5 впсок активно юзают рандом по диску - скорость будет выше, чем когда 40 впсок активно юзают рандом по диску.

- попробуйте запустить *nix + bind (или не важно что еще) на 64Мб - теоретически это возможно, практически - это не доставит Вам никакого удовольствия и по всюду будут ограничения и проблемы, малейшая нагрузка и все уйдет в свопирование. Для Вас это возможно, потому что на OpenVZ это не 64Мб, а 64Мб+ (в плюс попадает все что еще есть свободного на сервере), и пока у сервера есть еще какие-то ресурсы аккаунт чувствует себя нормально и работает на этих 64+ Мб ОП. Если Вы забьете весь сервер не оставив резерва по ОП такими аккаунтами, то окажется что все работает очень хреново, так как аккаунт получит 64Мб+0. Xen в этом плане абсолютно предсказуем - есть 256Мб ОП и если на них все работает, то оно и будет работать независимо от того как далеко простирается моя жадность.

- речь идет о разумной работе со своп разделами аккаунтов (советы очевидные любому сисадмину, типа - не делай своп на RAID 1, и т. д.)

- что касается диска, проблемы тут у всех технологий примерно одинаковые (можно и шаред вспомнить) - чем больше аккаунтов, тем больше проблем :) и решения тут те же что и на шаред - SAN и т. п.

У FastVPS на XEN давным-давно получилось ;)

Apache, который сильно колеблется в памяти от нагрузки, естественно, ставить на 64mb не надо. Но я точно знаю, что bind не сможет "внезапно" поднять свое использование памти в два раза.