seocore: вот вот, поэтому и надо предлагать 256Мб ОЗУ минимум ...
а не учить клиентов правильно писать скрипты, показать, что не надо 100 раз рендерить страничку, а можно ее одним махом в eaccelerator_put и никаких гвоздей и перегрузов MySQL 🚬
вообще люди берут ВПСку те, у которых, как правило, нет денег на сервер, а раз нет денег на сервер, то скорее всего нет денег и на администрирование сервера...
вот и оптимально предлагать сразу готовое рабочее решение под DirectAdmin/ISPManager/LxAdmin, на 256-512Мб ОЗУ, при этом, чтобы у клиента башка не болела по всяким "cannot allocate memory" на простеньком Drupal блоге с посещаемостью каких-то 500 хостов в сутки :D
Но ведь это решение, по мнению большинства клиентов, не должно быть на столько дороже шаред-хостинга, на котором все прекрасно работало, но с которого поперли за нагрузку!
Brim.ru: Тогда объясните почему они отказались от этого чудесного и выгодного тарифа? Сейчас у них минимальный тариф XEN-1 имеет 150 MB RAM и лично меня это ни сколько не удивляет, тарифы Xen с 64Мб это добровольная порча своей кармы ;)
Много клиентов на VPS-64 могут настроить его так, чтобы он работал, как надо? Много клиентов, вообще, в состоянии адекватно оценить тариф и то, что на нем можно?
А много клиентов, не способных настроить VPS-64 так, чтобы он работал, как надо, способны понять, что в этом виноват не хостер?
Brim.ru: - попробуйте запустить *nix + bind (или не важно что еще) на 64Мб - теоретически это возможно, практически - это не доставит Вам никакого удовольствия и по всюду будут ограничения и проблемы, малейшая нагрузка и все уйдет в свопирование. Для Вас это возможно, потому что на OpenVZ это не 64Мб, а 64Мб+ (в плюс попадает все что еще есть свободного на сервере), и пока у сервера есть еще какие-то ресурсы аккаунт чувствует себя нормально и работает на этих 64+ Мб ОП. Если Вы забьете весь сервер не оставив резерва по ОП такими аккаунтами, то окажется что все работает очень хреново, так как аккаунт получит 64Мб+0. Xen в этом плане абсолютно предсказуем - есть 256Мб ОП и если на них все работает, то оно и будет работать независимо от того как далеко простирается моя жадность.
У FastVPS на XEN давным-давно получилось ;)
Apache, который сильно колеблется в памяти от нагрузки, естественно, ставить на 64mb не надо. Но я точно знаю, что bind не сможет "внезапно" поднять свое использование памти в два раза.
Brim.ru: - чтобы такой проблемы на возникало, надо:
1. Не делать VPS c маленьким количеством ОП! IMHO, 128 Мб это тот минимум который позволяет Xen VPS работать без свопирования, но который нельзя использовать под мало мальски нагруженные сайты. А уж разговоры про 64Мб у меня постоянно вызывают, мягко выражаясь, недоумение и сомнение.
2. Как говорил тут кое-кто, "надо уметь их готовить" 😎 (я имею в виду свопы - кто в теме поймет, кто не в теме, тому и знать не к чему)
3. Если будет "плохо" это станет ясно сразу, а не когда жадный хостер забьет весь сервер аккаунтами по 64Мб. Если будет "хорошо", то ничего не изменится, даже если хостер забьет весь сервер аккаунтами. В этом плане Xen-виртуализация (с учетом правильного создания хостером свопов) существенно более предсказуема, в отличие от OpenVZ, где проблемы с диском также могут возникнуть при увеличении количества аккаунтов, а вот память на аккаунтах по 64Мб может исчезнуть совершенно неожиданно и как тогда будет работать софт, на гарантированных 64Мб, остается только гадать (а потом клиенты начинают рассказывать байки - был хороший хостер, да испортился, сначала летало все, а теперь еле ползает).
1. В принципе, согласен. Но под что-то простое и 64 хватит (например, bind под вторичный сервер, nginx чтобы отдавать статику на пару тысяч парковочных доменом, под ту же самую почту). Важно понимать, что для каждого случая - свой тариф.
2. Увы, мой опыт работы с XEN нулевой, знаю только теорию. Если не сложно, поясните.
3. А почему? Ведь когда 5 впсок активно юзают рандом по диску - скорость будет выше, чем когда 40 впсок активно юзают рандом по диску.
Если отойти от темы взаимных оскорблений, то немного задела следующая фраза:
>Как можно убить ноды, когда мы продаем ровно столько ресурсов, сколько можем? Если мы продаем 10 пользователям по одной десятой сервера, в сумме получается 1 сервер. Как его можно этим убить?
Сервер - это не только процессор и память. Например, я думаю, что тут не была учтена нагрузка на дисковую подсистему, а у XEN она больше, чем у *vz, так как он оперирует не с файлами, а с устройствами. Особенно плохо придется, когда впски начнут свопиться на свои виртуальные диски.
Кроме того, на виртуализацию так же существуют свои накладные ресурсы. Незначительные, но существуют.
Первым 5 заказавшим хостинг у нас с этого форума 2 месяца бесплатно!!!
У кого на форуме много сообщений и положительная репутация, условия будут еще лучше! пишите на support@kinghosting.ru
1) ulimit -c 0 спасет от корок.
2) при превышении памяти не создаются корки
3) лучше разобраться, от чего они создаются
Вы бы смайликов поменьше ставили, а то неделю назад я из-за вас более тысячи рублей потерял.
Сколько не сижу на форуме, вижу странную закономерность.
Жители тарифов за 2 доллара постоянно теряют тысячи рублей на суперважных сайтах.
вот привели бы ls списочек директории /vz/private/ на ваших нодах, можно было бы прикинуть какой оверселльчик допускает хостер :)
Ээ. А что это даст, кроме количества контейнеров? :)
вот вот, поэтому и надо предлагать 256Мб ОЗУ минимум ...
а не учить клиентов правильно писать скрипты, показать, что не надо 100 раз рендерить страничку, а можно ее одним махом в eaccelerator_put и никаких гвоздей и перегрузов MySQL 🚬
вообще люди берут ВПСку те, у которых, как правило, нет денег на сервер, а раз нет денег на сервер, то скорее всего нет денег и на администрирование сервера...
вот и оптимально предлагать сразу готовое рабочее решение под DirectAdmin/ISPManager/LxAdmin, на 256-512Мб ОЗУ, при этом, чтобы у клиента башка не болела по всяким "cannot allocate memory" на простеньком Drupal блоге с посещаемостью каких-то 500 хостов в сутки :D
Но ведь это решение, по мнению большинства клиентов, не должно быть на столько дороже шаред-хостинга, на котором все прекрасно работало, но с которого поперли за нагрузку!
Отсюда и тяга к VPS-64
Тогда объясните почему они отказались от этого чудесного и выгодного тарифа? Сейчас у них минимальный тариф XEN-1 имеет 150 MB RAM и лично меня это ни сколько не удивляет, тарифы Xen с 64Мб это добровольная порча своей кармы ;)
Много клиентов на VPS-64 могут настроить его так, чтобы он работал, как надо? Много клиентов, вообще, в состоянии адекватно оценить тариф и то, что на нем можно?
А много клиентов, не способных настроить VPS-64 так, чтобы он работал, как надо, способны понять, что в этом виноват не хостер?
Вот и весь ответ.
- попробуйте запустить *nix + bind (или не важно что еще) на 64Мб - теоретически это возможно, практически - это не доставит Вам никакого удовольствия и по всюду будут ограничения и проблемы, малейшая нагрузка и все уйдет в свопирование. Для Вас это возможно, потому что на OpenVZ это не 64Мб, а 64Мб+ (в плюс попадает все что еще есть свободного на сервере), и пока у сервера есть еще какие-то ресурсы аккаунт чувствует себя нормально и работает на этих 64+ Мб ОП. Если Вы забьете весь сервер не оставив резерва по ОП такими аккаунтами, то окажется что все работает очень хреново, так как аккаунт получит 64Мб+0. Xen в этом плане абсолютно предсказуем - есть 256Мб ОП и если на них все работает, то оно и будет работать независимо от того как далеко простирается моя жадность.
У FastVPS на XEN давным-давно получилось ;)
Apache, который сильно колеблется в памяти от нагрузки, естественно, ставить на 64mb не надо. Но я точно знаю, что bind не сможет "внезапно" поднять свое использование памти в два раза.
- чтобы такой проблемы на возникало, надо:
1. Не делать VPS c маленьким количеством ОП! IMHO, 128 Мб это тот минимум который позволяет Xen VPS работать без свопирования, но который нельзя использовать под мало мальски нагруженные сайты. А уж разговоры про 64Мб у меня постоянно вызывают, мягко выражаясь, недоумение и сомнение.
2. Как говорил тут кое-кто, "надо уметь их готовить" 😎 (я имею в виду свопы - кто в теме поймет, кто не в теме, тому и знать не к чему)
3. Если будет "плохо" это станет ясно сразу, а не когда жадный хостер забьет весь сервер аккаунтами по 64Мб. Если будет "хорошо", то ничего не изменится, даже если хостер забьет весь сервер аккаунтами. В этом плане Xen-виртуализация (с учетом правильного создания хостером свопов) существенно более предсказуема, в отличие от OpenVZ, где проблемы с диском также могут возникнуть при увеличении количества аккаунтов, а вот память на аккаунтах по 64Мб может исчезнуть совершенно неожиданно и как тогда будет работать софт, на гарантированных 64Мб, остается только гадать (а потом клиенты начинают рассказывать байки - был хороший хостер, да испортился, сначала летало все, а теперь еле ползает).
1. В принципе, согласен. Но под что-то простое и 64 хватит (например, bind под вторичный сервер, nginx чтобы отдавать статику на пару тысяч парковочных доменом, под ту же самую почту). Важно понимать, что для каждого случая - свой тариф.
2. Увы, мой опыт работы с XEN нулевой, знаю только теорию. Если не сложно, поясните.
3. А почему? Ведь когда 5 впсок активно юзают рандом по диску - скорость будет выше, чем когда 40 впсок активно юзают рандом по диску.
Если отойти от темы взаимных оскорблений, то немного задела следующая фраза:
>Как можно убить ноды, когда мы продаем ровно столько ресурсов, сколько можем? Если мы продаем 10 пользователям по одной десятой сервера, в сумме получается 1 сервер. Как его можно этим убить?
Сервер - это не только процессор и память. Например, я думаю, что тут не была учтена нагрузка на дисковую подсистему, а у XEN она больше, чем у *vz, так как он оперирует не с файлами, а с устройствами. Особенно плохо придется, когда впски начнут свопиться на свои виртуальные диски.
Кроме того, на виртуализацию так же существуют свои накладные ресурсы. Незначительные, но существуют.
man chkconfig
Ок, кидайте wmid и кошелёк.
Или, давайте по:
Первым 5 заказавшим хостинг у нас с этого форума 2 месяца бесплатно!!!
У кого на форуме много сообщений и положительная репутация, условия будут еще лучше! пишите на support@kinghosting.ru