company_banner

Наш опыт оптимизации 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
    Southbridge 121,65
    Обеспечиваем стабильную работу серверов
    Поделиться публикацией
    Комментарии 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 примерно тоже самое, но на мой взгляд, просматривать графики в нем удобнее.

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

                      Самое читаемое