zzzit

Давайте посчитаем, ресурсов SSD очень много - нет смысла резать агрессивно, врядли попадется даже хоть кто-то один на сервер, кто и 30% загрузит, потому достаточно ограничить лимитом скажем в 30%, т.е. грубо 150 мбайт/с и 15000 IOPS. А чем могут похвастаться VPS на 10k HDD? 10 мбайт и 20 IOPS? Ну-ну. VPS на SSD панацея.

Да, они такие. Было как-то в лимит трафика уперлся в каком-то из наших ДЦ - хостер заявил: возьмите сервер подороже, там лимит больше :)

А по существу - любой дешевый SSD VPS должен решить все проблемы.

Den73, расскажите, каким образом юридически законно взять чужие файлы, разорвать договор, но не отдать их назад?

Если бы клиент обратился к юристам, хостер бы темой на форуме не отделался.

Только в том случае, если это "ВСЕ" полностью законное и никакие права клиента нигде не ущемляет, что мало вероятно.

Вообще этот совковый подход уже надоел. Клиент всегда прав, даже если он не прав.

Сори, не поверю. Покажите скрин матрицы тестов.

В cpanel пишут 100% и у них даже есть люди, которые только QA занимаются

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

CFQ или какой сейчас популярный, cat /sys/block/sda/queue/scheduler

---------- Добавлено 21.07.2013 в 21:00 ----------

2250 сферических в вакууме. Клиенты разные, кто-то быстрый, кто-то медленный, битрейт разный, можно шейпить, можно не шейпить, плеер может буферизировать весь файл, а может по чуть-чуть. Если не шейпить и плеер буфферизирует не весь файл, то быстрые клиенты не будут занимать много памяти, данные будут долго висеть в памяти только для медленных. Сколько медленных останется? Это не так все однозначно.

Смотрите, если несколько запросов пришли одновременно они могут быть обработаны двумя способами: послать все их в ядро и ждать ответов от всех сразу постепенно посылая запросы еще, как в случае с aio или послать один запрос на 2 мегабайта, подождать ответа, послать второй, подождать ответа, послать третий, подождать ответа и т.д. В первом случае они будут обрабатываться на усмотрение планироващика, который будет стараться угодить всем сразу в ущерб пропускной способности, а во втором случае у планировщика всегда только один запрос и полный контроль над тем, сколько данных за один запрос мы можем получить остается у нас и позволяет минимизировать количество позиционирований головки. Естественно, если пришло 3 запроса и ответ от диска занимает 30 мс, то первый клиент начнет получать ответ через 30 мс, второй через 60 мс, третий через 90 мс, но это незаметно для посетителей.