1it Dec 30 2013 at 12:12

Наш опыт оптимизации nginx для раздачи видео-контента

3 min

20K

Слёрм corporate blog

Comments 25

ksdaemon Dec 30 2013 at 13:36

Я чего-то не понял: вся статья про то, как увеличить размер буфера в nginx?

1it Dec 30 2013 at 13:42

Статья про то, как успешно увеличить размер буфера в nginx и сделать всем хорошо. :)
Ну или просто одна из наших небольших «success story» по итогам года.

opium Dec 30 2013 at 16:48

Фигня, в nginx достаточно выставить чтение блоками и почти все чтение для файлов станет из рандомного в линейное, выдает на рейде в легкую полтора гигабита.

1it Dec 30 2013 at 17:09

Если вы не заметили, в нашем конфиге включен aio и directio.

opium Dec 30 2013 at 17:11

У вас все равно всего на 400 мегабитах винт упирается в полку и это печаль.

1it Dec 30 2013 at 17:18

Учтите, что у нас 4 обычных (SATA III, 7200RPM) диска в RAID-10.
Да и не упирается толком, еще небольшой запас есть.

opium Dec 30 2013 at 17:19

У меня тоже было 5 обычных дисков в рейд 6
А думаю за три года обычные диски стали только быстрее, да и сата3 у васа не сата 2 как у меня.

1it Dec 30 2013 at 17:27

Может тогда, объясните как сделать лучше? Думаю всем будет интересно. Я пока не понял в чем особенность вашего подхода.

UFO landed and left these words here

1it Dec 30 2013 at 18:22

Речь о псевдостриминге и даже просто о стриминге не велась, не путайте теплое с мягким. И что, по-вашему мы должны были все наши знания уместить в одном локейшене? Интересно вы рассуждаете. :)
Второй комментарий вообще не понятно к чему, вы что считаете что мы за каждый чих «такие» деньги берем?

UFO landed and left these words here

1it Dec 30 2013 at 19:03

Приведенный локейшен предназначен для раздачи статики, и к стримингу никакого отношения не имеет, думаю это ясно как день.
Данная статья не мануал и не howto, а просто небольшая заметка в блоге нашей компании, если кто-то еще не заметил. Если бы мы хотели задумать полноценную статью про оптимизацию раздачи статики (в том числе и видео-файлов), тогда здесь были бы полные конфиги с подробным описанием всех директив и параметров.

UFO landed and left these words here

VBart Dec 30 2013 at 22:08

Выделение части оперативной памяти под раздел с кешем — решение не совсем правильное, ядро Linux (мы используем только Linux) и так неплохо справляется с кешированием, да и свободной оперативной памяти бывает не всегда достаточно.

Стоит заметить, что вы выключили page cache для запросов от 512 байт, так что последний фактически у вас не используется. Хорошо это или плохо — зависит от соотношения объема частозапрашиваемого контента и объема ОЗУ. Вероятно для mp3 следовало бы выключить directio совсем, либо поставить какое-нибудь более вменяемое значение (например directio 8m).

И стыдно должно быть такие регулярные выражения писать.

1it Dec 30 2013 at 22:33

Хм, ну на самом деле, это всего лишь кусок от реально используемого регулярного выражения, которое я сократил для статьи. Хотя в принципе его можно было и еще короче сделать, поскольку из контента в данном случае есть только картинки (jpeg, gif, png) и видео файлы (mp4, 3gp, flv, avi). Насчет mp3, хоть здесь он и не используется, но спасибо за совет. Начет page cache, не думаю, что здесь это сильно скажется, портал исключительно «мобильный», при том что >= 98% контента это видео-файлы.
Поясните про регулярное выражение, чем оно так вам не понравилось?

VBart Dec 30 2013 at 22:46

Во-первых, неужели там действительно помойка? И все эти файлы смешаны и разбросаны по всему сайту, так что вообще понадобилось писать регулярку вместо какого-нибудь location /video/ { .. }?

Во-вторых, по поводу самой регулярки, даже не нужно каких-либо глубоких знаний pcre, чтобы её элементарно оптимизировать: \.(?:jpe?g|gif|png|ico|css|bmp|js|swf|flv|avi|djvu|mp[34]|3gp)$, и да, много у вас ico и bmp на сайте?

1it Dec 30 2013 at 23:36

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

VBart Dec 30 2013 at 22:52

в данном случае есть только картинки (jpeg, gif, png)

Вот они бы все и пошли в ядерный кэш и не дергали диск понапрасну, каждая такая картинка наверняка часто запрашивается, а приводит к дорогому seek-у.

Значение directio 512 выглядит неадекватным в таком локэйшене.

1it Dec 30 2013 at 23:36

Здесь я соглашусь с вами, спасибо за замечание.

1it Dec 31 2013 at 00:23

Видимо имеет смысл вынести картинки и прочую мелочь в отдельный location:

location ~* \.(?:jpe?g|gif|png||css|js)$ {
root   /path/to/static-content;
expires max;
}

maxkhiger Jan 11 2014 at 12:28

Ребят, глянул Ваши цены на centos-admin.ru. Пожалуй это top-цены, т.е. наиболее высокие на рынке услуг системного инжиниринга, которые я встречал.

У меня вопрос такой первый — и что большие компании идут на такое? Если да, то зачем?

Предположим, что у нас инфраструктура 20+ серверов. Я посчитал и выходит, что взять двух своих системных администраторов на зарплаты 80-90 тыс. рублей достаточно высокого уровня компетентности и опыта — получается на порядок выгоднее.

Какими «пряниками» Вы в плане ценообразования завлекаете своих клиентов?

И какие гарантии безопасности конфиденциальных данных клиента Вы даете, с учетом, что у Вас толпа людей работает, каждый из которых потенциально может слить что угодно и никто даже не заметит?

velikan5 Feb 4 2014 at 14:42

А подскажите, как Вы сделали такие потрясающие графики?
Если вдруг будет удобно — поделитесь мануалом, как это всё настроить на своём серваке.
Спасибо.
Удачи!

1it Feb 4 2014 at 14:46

Cacti или Zabbix вам в помощь. :) Мануалов на эту тему уже достаточно много.

velikan5 Feb 4 2014 at 15:34

а конкретно откуда именно такие получаются — Cacti или Zabbix?

1it Feb 4 2014 at 15:44

В данном случае Cacti. В zabbix примерно тоже самое, но на мой взгляд, просматривать графики в нем удобнее.