company_banner
30 декабря 2013 в 12:12

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

Наша компания обслуживает множество крупных интернет порталов различной тематики. Специфика подобных проектов подразумевает возникновение различных трудностей при росте аудитории, а значит и росте нагрузки на серверы. Один из наших клиентов активно продвигает свой видео-портал, и, как результат, нагрузка неминуемо стала расти, причем большими темпами. В какой-то момент обойтись двумя серверами стало уже невозможно и было принято решение добавить еще два. Затем еще два… в итоге серверов стало 12. Однако, нагрузка продолжает расти и одним только горизонтальным масштабированием ограничиваться нельзя. Настало время задуматься о более глубокой оптимизации.


Итак, всем, конечно, известно, что с раздачей статики лучше всего справляется nginx. Само собой, при должной оптимизации конфигурации. Этот проект не стал исключением — Nginx и раздает всю статику. В основном, это графический и аудио/видео-контент, в частности видео файлы размером от 50-ти Мб до 2-х Гб. Со своей задачей nginx прекрасно справляется, к тому же опыта в его тонкой настройке наш коллектив набрал уже достаточно много. Но, так или иначе, проблемы всегда возникают, а их решения не всегда лежат на поверхности. В нашем случае стали возникать трудности в пики нагрузки, когда на портале выкладывали “свежую порцию” видео-контента. Если говорить простым языком — система упиралась в диски. Стопроцентная нагрузка на дисковую подсистему могла длиться несколько часов к ряду, как видно на графике ниже.


Как результат — очень низкая скорость отдачи контента и недовольные пользователи.

Часть конфигурационного файла отвечающего за раздачу статики на тот момент:
location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|js|swf|flv|avi|djvu|mp3|mp4|3gp)$ {

        aio on;
        directio 512;
        output_buffers 1 512k;

        root /srv/www/htdocs;

}

Как можно улучшить ситуацию в подобных случаях? Есть много статей на Хабре (и не только) на эту тему и в комментах к ним много полезных подсказок. Есть мнение, что быстрый SSD-кеш это лучше решение для раздачи статики. Кто-то считает кеш в VFS хорошим для большого количества мелких файлов, пока оно умещается в рамки выделенного раздела. Вариант SSD, возможно, хорош, но не всем подходит, поскольку иногда просто нет физической возможности добавить еще один диск, не говоря уже о паре. Выделение части оперативной памяти под раздел с кешем — решение не совсем правильное, ядро Linux (мы используем только Linux) и так неплохо справляется с кешированием, да и свободной оперативной памяти бывает не всегда достаточно.
В нашем случае свободной оперативной памяти было достаточно много (до 90% из 16 Гб на каждом сервере). Но как ее можно правильно использовать? Было принято решение увеличить буфер отдачи с 512 Кб до 8 Мб:
location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|js|swf|flv|avi|djvu|mp3|mp4|3gp)$ {

        aio on;
        directio 512;
        output_buffers 1 8m;

        root /srv/www/htdocs;

}

Этого оказалось достаточно, чтобы снизить нагрузку на диски в среднем в полтора-два раза. Потребление оперативной памяти веб-сервером при этом значительно возросло (в среднем от 70 до 90% от общего объема).
На графике ниже видно как менялась нагрузка на диск после оптимизации:


График сетевой нагрузки. Исходящий трафик вырос в среднем в полтора-два раза:


График изменения потребления оперативной памяти после оптимизации:



В результате экспериментов с настройками буферов скорость отдачи контента в пики нагрузки составила в среднем 1 Мб/с на каждого пользователя, что является вполне приемлемым результатом. Сервис работает стабильно, клиент доволен, пользователи тоже.

Полезные статьи:
Nginx Wiki
Тюнинг nginx
Ускоряем Nginx за 5 минут
Nginx Secure Web Server
Автор: @1it
Southbridge
рейтинг 199,26
Обеспечиваем стабильную работу серверов
Похожие публикации

Комментарии (25)

  • +6
    Я чего-то не понял: вся статья про то, как увеличить размер буфера в nginx?
    • –4
      Статья про то, как успешно увеличить размер буфера в nginx и сделать всем хорошо. :)
      Ну или просто одна из наших небольших «success story» по итогам года.
  • +1
    Фигня, в nginx достаточно выставить чтение блоками и почти все чтение для файлов станет из рандомного в линейное, выдает на рейде в легкую полтора гигабита.
    • –1
      Если вы не заметили, в нашем конфиге включен aio и directio.
      • +1
        У вас все равно всего на 400 мегабитах винт упирается в полку и это печаль.
        • –1
          Учтите, что у нас 4 обычных (SATA III, 7200RPM) диска в RAID-10.
          Да и не упирается толком, еще небольшой запас есть.
          • 0
            У меня тоже было 5 обычных дисков в рейд 6
            А думаю за три года обычные диски стали только быстрее, да и сата3 у васа не сата 2 как у меня.
            • 0
              Может тогда, объясните как сделать лучше? Думаю всем будет интересно. Я пока не понял в чем особенность вашего подхода.
  • 0
    В энжинксе кстати ещё и псевдостриминг есть =) А то по лакейшену не похоже что вы об этом знаете.

    P.S. зашел к вам на сайт и прифигел. За такие деньги поднять буфер это… круто =)
    • 0
      Речь о псевдостриминге и даже просто о стриминге не велась, не путайте теплое с мягким. И что, по-вашему мы должны были все наши знания уместить в одном локейшене? Интересно вы рассуждаете. :)
      Второй комментарий вообще не понятно к чему, вы что считаете что мы за каждый чих «такие» деньги берем?
      • 0
        Да просто речь вроде про настройку nginx для раздачи видео, в лакейшане mp4 и flv есть, а упоминания стрименга нет.

        Если пишите статью, то приводите полный и подробный конфиг. Расписывайте почему используйте такие то параметры, а не другие. На что это влияет и т.д. Тогда и статья будет нормальной а не духе одной строчки: «буферы это круто».

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

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

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

      Значение directio 512 выглядит неадекватным в таком локэйшене.
      • 0
        Здесь я соглашусь с вами, спасибо за замечание.
        • 0
          Видимо имеет смысл вынести картинки и прочую мелочь в отдельный location:
          location ~* \.(?:jpe?g|gif|png||css|js)$ {
          root   /path/to/static-content;
          expires max;
          }
          

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

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

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

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

    И какие гарантии безопасности конфиденциальных данных клиента Вы даете, с учетом, что у Вас толпа людей работает, каждый из которых потенциально может слить что угодно и никто даже не заметит?
  • 0
    А подскажите, как Вы сделали такие потрясающие графики?
    Если вдруг будет удобно — поделитесь мануалом, как это всё настроить на своём серваке.
    Спасибо.
    Удачи!
    • 0
      Cacti или Zabbix вам в помощь. :) Мануалов на эту тему уже достаточно много.
      • 0
        а конкретно откуда именно такие получаются — Cacti или Zabbix?
        • 0
          В данном случае Cacti. В zabbix примерно тоже самое, но на мой взгляд, просматривать графики в нем удобнее.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное