Превышен лимит на ввод/вывод

"Прикольно" думать, что SSD имеют очень малый срок эксплуатации, kingston пользуюсь, в ноуте HyperX FURY SSD - 3 года гарантии, накопители SSDNow KC400 - 5 лет гарантии, на работе на каких-то 10 лет было. А если вы думаете что на минимальном тарифе ограничения CPU, RAM и т.д. вам позволят "иметь" диск то вы ошибаетесь.

Хостер который не лимитирует нагрузку это хостер который не думает о благе клиентов.

Бежать от такого хостера надо, а не переезжать к нему.

ТС рекомендую разобраться в том что такое лимиты и понять, что безлимитного в мире нет. За все нужно платить.

А CloudLinux придумали конечно идиоты и 95% хостеров в мире которые используют CloudLinux тоже идиоты.

95% хостеров ими и есть :)

CloudLinux самое идиотское ПО в хостинге. В гонке за высокой плотностью они как-то забыли, для чего вообще хостинг существует и дошли до того, что сайты больше не могут просто работать, а чуть что перестают.

Хостеров не виню за это, хостеры потому и покупают CloudLinux, что своими силами ничего не могут.

Ну, я не так выразился. Есть менее жесткие ограничения на ресурсы. И это не значит что хостинг должен быть какой то не серьезный, вовсе нет. Хостинг виноват очень часто, точнее настройки серверов. Конечно, сами сайты посмотреть интересно.

А кто загнал хостеров в погоню? Какие клиенты, такие и хостеры:) CloudLinux это просто ПО. Руки надо прилагать и голову. Вполне удобное, особенно для хостеров не имеющих в штате хороших системных программистов или не желающих на это тратиться. CloudLinux вовсе не только лимитер ресурсов. Из 1000 клиентов от силы 5-6 выходят за пределы лимитов. Бывало в свое время, мы пробовали прибавлять таким клиентам ресурсов - никогда не помогало, потому что дело было вовсе не в лимитах, а:

1) кривых движках, их темах или плагинах или других не очень грамотных "усовершенствованиях". -99%

2) реальной нехватке ресурсов сервера для работы сайта(ов) - таким приходится переходить на ВПС или VIP хостинг - оставшийся 1%.

Это что касается работы сайтов в штатном режиме. Если на клиента идет флуд или ддос, CloudLinux начинает его лимитировать. Но это естественно, так как с какой стати все клиенты должны страдать из-за одного клиента?

Также CloudLinux не любит т.н. "хабраэффекта". И понятно почему, он на него вовсе не рассчитан. И любой шаред хостинг на него не рассчитан. На него рассчитан кластерный хостинг или, если кому-то это больше нравится - "облачный" хостинг имеющий техническую возможность распределить нагрузку с одного сервера на другой или даже, с одной серверной фермы на другую без остановки сервисов и автоматически. Само собой это стоит дороже, так как те самые ноды, которые подключаются по мере необходимости, простаивают в резерве и за этот резерв клиент хостеру должен платить.

Кроме того, CloudLinux обеспечивает базовую система безопасности: невозможность клиентам видеть файлы друг друга, защита ядра О/С и прочее (во многом на базе grecurity, но сильно упрощенной и оптимизированной под конкретные хостерские задачи).

Как любое ПО, CloudLinux имеет свои плюсы и минусы, но учитывая показанное выше, плюсов заметно больше. Безусловно, можно настроить все то же самое самим и сделать лимитирование более гибким, но это все равно не решит проблемы нехватки ресурсов на сервере. Выше головы не прыгнешь...

Грамотно описали, поддержку Ваше мнение о CloudLinux.

Не по теме конечно

Но хотелось бы конечно услышать от недовольных CloudLinux'ом - её минусы :)

Ну кроме лимитов, это не минус ОС, а CMS/хостера

CMS: в плане оптимизации/ кол. посещений сайта

Хостера: (возможно) Только в том, что лимиты слишком низкие выставлены

сервера с CloudLinux чаще в падают в kernel panic, Load Average считается по своему (куча тасков), зависимость от сторонних разработчиков, в некоторых ситуациях ставит пользователя в тупик т.к он не может понять из за чего у него не работает программа, небольшой оверхед.

часто на таких хостингах сайты складываются быстрее и держат меньшую нагрузку из за ограничений, но это не проблема CloudLinux.

CloudLinux идеален для тех кто хочет экономить на админах и не тратиться на высококвалифицированных специалистов.

Den73, kernel panic не было в принципе за 3 года ни разу (тьфу/тьфу/тьфу)

LA - это понятное дело, не обращаем внимания на него, следим за CPU / i-o (аналогично как на нодах с OpenVZ, LA скачет то 200 то 5, при этом естественно что нода свободна по ресурсам, а проблема конкретно одного контейнера)

про оверхед тоже понятно), что он будет

LA - это вообще довольно левый показатель. На нагруженных серверах он и 500 может быть и при этом все будет летать. Кернел паник не было никогда (пользуем CL с 2008 года, как появился в общем. До этого использовали Grsecurity с небольшими допилками, но трудозатратненькое было дело).