mp4 streaming tuning
Вадим Лазовский
vadim.lazovskiy at gmail.com
Mon Dec 17 08:18:36 UTC 2012
17 декабря 2012 г., 11:42 пользователь Oleg Palij <o.palij at dp.uz.gov.ua>написал:
> 17 дек. 2012, в 08:40, Вадим Лазовский написал(а):
>
> nginx/1.2.3 стримит видео, упираемся в 1.5 Гб/c (две 1Гб сетевухи в bond)
>> и nginx начинает с задержкой в начале (несколько секунд, иногда до минуты)
>> отдавать файлы, при этом iowait 20-30%, si ~ 20%.
>
> moov-атом точно перенесен в начала файла? Во всех файлах?
>
> Точно.
>
> Вот это место я бы перепроверил. Уж очень подобное поведение похоже на то,
что описано в документации:
"Если файл отформатирован хорошо, с метаданными в начале файла, nginx
просто посылает в ответ содержимое файла. В противном случае, он вынужден
будет прочитать файл и подготовить новый поток, в котором метаданные
предшествуют медийным данным. Это требует дополнительного процессорного
времени, памяти и дискового ввода/вывода, поэтому лучше подготовить
исходный файл для
псевдо-стриминга<http://flowplayer.org/plugins/streaming/pseudostreaming.html#prepare>,
нежели чем заставлять nginx делать это для каждого запроса."
Выключите mp4, просто раздавайте файлы без обработки. Будет ли тот же
эффект?
>
>
>> Популярные файлы лежат на ssd, остальное на hdd.
>
> Сколько всего ssd и обычных дисках. И не в массивах ли они часом?
>
> 1 ssd и 6 hdd в software raid5.
>
> В свое время намучились с raid5. Линейное чтение - великолепно, но как
только появляется сотня-другая клиентов - начинается затуп.
С тех пор только отдельные диски или raid10. Чего и вам желаю.
> Без aio отдаем 4 Гбит.
>
> С включенным sendfile? directio для очень больших файлов
> включен? output_buffers тюнили?
>
>
sendfile включен. Все остальное, кроме "timer_resolution 100ms;"
по-умолчанию.
sysctl.conf:
net.ipv4.tcp_tw_recycle = 1
net.core.wmem_default = 262144
net.core.wmem_max = 4194304
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.ipv4.tcp_rmem = 8192 262144 4194304
net.ipv4.tcp_wmem = 8192 262144 4194304
> Мб воткнуть третий линк и добавить памяти?.
>
> А зачем третий линк, если два не утилизируются полностью? Память,
> к сожалению, не добавить.
>
> Это на случай, если упирается в прерывания, хотя, кажется, дело не в этом.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20121217/37270483/attachment.html>
Подробная информация о списке рассылки nginx-ru