Задать вопрос

Выбор файловой системы для сервера с видео?

Здравствуйте. Суть: есть сайт с фильмами, на котором хранятся сами фильмы, и, соответственно, воспроизводятся. Возникает проблема с нагруженностью на диск, из-за этого скорость чтения и отдачи файлов намного снижается. Стоит RAID 0 LVM, объём 2х2ТБ. Как быть? В какую сторону копать? Что бы предприняли Вы? Спасибо.
  • Вопрос задан
  • 3757 просмотров
Подписаться 4 Оценить 9 комментариев
Пригласить эксперта
Ответы на вопрос 6
Jump
@Jump Куратор тега Системное администрирование
Системный администратор со стажем.
Во первых подумайте- зачем вам RAID 0 ?
В данной ситуации он мало того что бесполезен, так еще и вреден.
Нулевой рэйд из двух дисков способен поднять скорость линейного чтения почти в два раза. У вас не линейное чтение, а множество случайных запросов получается при такой нагрузке, так что толку от него практически нет. Два независимых диска по которым раскиданы фильмы в данной ситуации будут работать быстрее!

Посмотрите статистику - насколько равномерно пользователи смотрят видео, какие файлы более популярны, какие менее?
Если есть ярко выраженные лидеры просмотров скачиваний - тогда добавьте SSD диск, и храните на нем самые популярные видео.
В этом случае не нужно будет тратиться на SSD огромного объема, а запросы будут раскиданы на три диска, причем основная доля запросов будет приходится на SSD c "горячими" данными.
Если нет возможности выделить "горячие данные" и все видео просматриваются одинаково часто, можно пойти путем простого увеличения количества дисков.
Например вместо 2hdd*2Тб использовать 4hdd*1Тб - и без всяких рейдов. Нагрузка в этом случае распределится более менее равномерно между четырьмя дисками.

Файловая система в идеале - XFS.
Ответ написан
leahch
@leahch Куратор тега Linux
3D специалист. Dолго, Dорого, Dерьмово.
Ну, про XFS (и тем более SSD) вам уже написали... Я же немного с другой стороны подойду. Как обычно, подозреваю, что стоит веб-сервер, который это видео раздает на сайт, а со стороны клиентов стоит браузер с flash или подобное. Другими словами, у вас стриминг видео. Что делает плеер со стороны клиента, кроме того, что проигрывает видео? А он ещё его и кеширует! А как он его кеширует?! А кешируют эти сволочи на сколько у них ресурсов хватит, спользуя весь объем диска и всю полосу пропускания!!!
Объясню на пальцах, клиент сморит ролик с битрейтом 3000килобит, а кешируется у него этот ролик на скорости клиентского подключения (100мегабит к примеру) и будет продолжать кешироваться до полной закачки всего файла. Теперь у нас 10 клиентов, которые тут же сожрали все ресурсы сервера и пропускной способности, на короткое время конечно, но пользователи прибывают например раз в 3 секунды, и вот они уже никаких ресурсов не получают вообще, пока первые 10 не докачают. А теперь представим, что первые 10 клиентов посмотрели только первые 3 минуты ролика и переключились на другой. Но мы то им отдали за эти три минуты двухчасовой ролик!
Что делать? Да очень просто, ограничить скорость на клиента двойным максимальным битрейтом. Это можно сделать как iptables/tc , так и политиками на nginx например. Ну или отдавать в формате HLS или подобном, или ставить ПО видеосервера, что в общем почти одно и тоже...
Вот как раз даже в примере есть (не просто так поди) www.nginxtips.com/how-to-limit-nginx-download-speed
location ^~ /videos/ {
...
limit_rate_after 1m;
limit_rate 150k;
...
}

PS. И да, кодируйте видео в CBR для раздачи. VBR для этого не очень подходит...
Ну, кажется все военные тайны раскрыл... Ну и дополнительно на HLS уходите!
Ответ написан
Ernillew
@Ernillew
Администрирую *nix-системы с 1997 года
По ФС стоит смотреть в сторону XFS, безусловно. А так смотрите на SSD, жесткий диск всегда будет медленней SSD.
Ответ написан
@386DX
Очевидное мнение виндовоза
есть линейная скорость чтения диска, есть скорость чтения случайных кластеров.
По линейному чтению жесткие диски нормальные диски выдают до 150мБ/c
crystal.jpg что перекрывает гиговый интернет канал.
На рандомных запросах скорость диска всего несколько мегабайт в секунду из за-механики (ограниченное число головок, низкая скорость вращения дисков, долгое время позиционирования головок на нужный кластер). Число IOPS до 200 операций\с

При большом количестве пользователей узкое место это IOPS.
Что делают под виндой
а) увеличивают размер кластера ФС до максимального (но не выше 64-128кБ)
б)увеличивают кэш на чтение в оперативной памяти или на отдельный SSD
в) переходят на SAS SSD и проч.

Прежде чем что-то делать, определитесь со своими нагрузками по IOPS и тогда будет видно, хватит ли перехода на ФС, добавления оперативы под кэш или нужен только SSD

А вообще, оптимизации на чтение малоэффективны, лучше менять железо.
Ответ написан
@ShamblerR
1. копайте в сторонуу катала связи.
Вопервых даже обычный SATA и даже IDE диск быстрей 1GB канала связи. и уж тем более при больших размерах файлов.
так что самое узкое метсо у вас это сам канал.
Что касается рейда
что показыает iotop -oka
под нагрузкой ?
проблемы же со скоростью "поиска файла" КАК ПРАВИЛО ПРИ БОЛЬШЕМ КОЛИЧЕСТВЕ МЕЛКИХ ФАЙЛОВ А НЕ НАОБОРОТ!
Ответ написан
@AlexLIn
Как насчет ZFS или Windows Storage Spaces c кэшем на SSD?
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы