>[оверквотинг удален]
>>>150 на SAS дисках вполне себе будут работать. На PVC(за счет vzfs)
>>>еще больше.
>>
>>Эм. Я имел в виду отнюдь не статику, а всякую фигню типа
>>WordPress, Django и Drupal… Тут диски, конечно, тоже важны, но упирается
>>всё по моему хостерскому опыту в первую очередь в CPU.
>
>Я и имела ввиду, 150 нагруженных тяжелыми приложениями (не только web) контейнеров.
>
>Но под такое уже лучше (если это не только web) sas raid10. Хм-м. Может, мы с вами о разном железе говорим. 150 сайтов с PHP, из них десяток более-менее посещаемых — это несколько лет назад был предел для одной платформы на Xeon'ах с эдак восемью процессорными ядрами (а если ещё добавить HyperThreading, то все 16+ ядер). Активный DDoS создавал свои проблемы (к слову, привет Яндексу), но отнюдь не с дисками. :)
>У OVZ и PVC есть неприятная особенность, которую не найдете в документации,
>хотя часто встречается на форумах и в рассылке: когда хватает дисковых
>iops, дисковый шедуллер разруливает iops'ы между контейнерами правильно, в соотвествии с
>их приоритетами.
>Как только iops начинает не хватать, cfq не может нормально разрулить дисковый
>ввод-вывод, и все встает колом в D.
Любопытно, спасибо.
>На шаред-хостинге в таком случае просто отрубают сайт-источник проблем, для внутренних сервисов
>так не поступишь(разве что, перенести на другую, более свободную железку),
>поэтому на диской подсистеме, для нормальной изоляции сервисов, лучше не экономить.
Это понятно, просто с посещаемыми сайтами в итоге, повторюсь, всё обычно упирается в CPU.
>Кроме того, и на шаред-хостинге SAS зеркало для двухсокетовой машины это не
>такое уж и барство.
Смотря на каком. В конторе, где я работал, ставили RAID5 + 1-2 hot spare, на SCSI/SAS. Проблем с пропускной способностью дисков не было.
>>>Кроме того, внутренний хостинг приложений для разных отделов/задач/проектов это тоже реальность, и
>>>тут тоже нужна хорошая изоляция (так как могут вынести мозг, если
>>>железка будет положена сервисами соседнего отдела)
>>
>>Можно динамически менять приоритеты, не проблема.
>
>Не удобно :(
Кому как. Мониторинг всё равно надо вести, так что…
>[оверквотинг удален]
>>>>>других сервисов, последним его достанется меньше.
>>>>
>>>>Значит, достаточно уменьшить разницу в приоритетах.
>>>
>>>Это просто неудобно.
>>
>>Э-э-э, что неудобно, сказать renice?
>
>Да. Проще поставить cpulimit, и спать, не просыпаясь ночью от SMS от
>мониторинга :)
Ну в общем-то да, проще каждому заключённому в тюрьме нарастить стены внутрь камеры с помощью железобетона, чем нанимать тюремщиков… Но всё же полагаться только на систему мониторинга не стоит. В конце концов, она тоже может сбойнуть или вообще отказать…
>>>Это уже сложности и неудобности (Вы скрипты предлагаете писать?)
>>
>>Не обязательно, хотя при желании можно и какую-нибудь автоматическую мониторилку сделать хоть
>>на shell, которая будет делать renice 20 виновнику при превышении порога
>>загрузки системы.
>
>Это все костыли, по-моему, Вы сами понимаете...
Можно сказать и так, хотя с другой стороны, больше своей гибкости… В общем, задачи, повторюсь, решаемые. :)
