- PVSM.RU - https://www.pvsm.ru -
Наша компания обслуживает множество крупных интернет порталов различной тематики. Специфика подобных проектов подразумевает возникновение различных трудностей при росте аудитории, а значит и росте нагрузки на серверы. Один из наших клиентов активно продвигает свой видео-портал, и, как результат, нагрузка неминуемо стала расти, причем большими темпами. В какой-то момент обойтись двумя серверами стало уже невозможно и было принято решение добавить еще два. Затем еще два… в итоге серверов стало 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 [1]
Тюнинг nginx [2]
Ускоряем Nginx за 5 минут [3]
Nginx Secure Web Server [4]
Автор: 1it
Источник [5]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/linux/51866
Ссылки в тексте:
[1] Nginx Wiki: http://nginx.org/ru/docs/http/ngx_http_core_module.html
[2] Тюнинг nginx: http://habrahabr.ru/post/56497/
[3] Ускоряем Nginx за 5 минут: http://habrahabr.ru/post/198982/
[4] Nginx Secure Web Server : https://calomel.org/nginx.html
[5] Источник: http://habrahabr.ru/post/207834/
Нажмите здесь для печати.