Comments 69
Спасибо, очень полезные советы.
Насчет рекомендации использовать SSD под не часто меняющийся контент (но он в люббом случае меняется, хоть и очень медленно) проверенно на личном опыте? Или просто — жертва маркейтинга?
(Много где читал что SSD со временем начинают ужасно тормазить, или уже пофиксено?)
(Много где читал что SSD со временем начинают ужасно тормазить, или уже пофиксено?)
Тормозят даже на чтении? Если так, то у них-таки есть seek-to-seek
4 SSD самсунга в RAID-е, если на него замонтировать /var/lib/mysql жывут 4 месяца потом сыпятся все одновременно (эта инфа из опыта моего знакомого, который провел експеримент на одном из хостинг-серверов). Я советую посмотреть в сторону SSD Intel x25m он только недавно поступил в продажу, этот должен выдержать.
Хороший материал, что ещё сказать.
Для того, чтоб виртуальный диск создавался автоматически при перезагрузке в /etc/fstab добавляем
none /var/www/img_virtual tmpfs size=1g,mode=1777 0 0
а откуда там возьмутся эти статические файлы? :)
Очевидно, что туда их нужно скопировать :).
Я обычно делаю сабдомены:
/var/www/img_virtual/img.hostname1
/var/www/img_virtual/img.hostname2
и вытягиваю из svn репозитория туда только папки /js, /css, /img соответствующего проекта
В теплейтах пишу полный путь img.hostname1/img/picture.jpg.
Как оказалось эти папки занимают очень мало места.
Мне, в определенный момент, все это сильно помогло.
Я обычно делаю сабдомены:
/var/www/img_virtual/img.hostname1
/var/www/img_virtual/img.hostname2
и вытягиваю из svn репозитория туда только папки /js, /css, /img соответствующего проекта
В теплейтах пишу полный путь img.hostname1/img/picture.jpg.
Как оказалось эти папки занимают очень мало места.
Мне, в определенный момент, все это сильно помогло.
А Вы можете объяснить, почему Вам помогло использование tmpfs?
Мне не понятно, зачем советуют tmpfs для статики.
Мне не понятно, зачем советуют tmpfs для статики.
nginx при отдаче любого файла производит запись и чтение на диск. Да-да запись тоже производит, например апдейтит last access time!
При небольшом числе запросов с этим неплохо справляется обычный винчестер, когда число запросов к этому файлу растет отдача начинает тормозить.
Поместить файлы в виртуальную fs значит максимально ускорить процесс чтения/записи и убрать «узкое горлышко» скорость работы механической части вашего сервера.
При небольшом числе запросов с этим неплохо справляется обычный винчестер, когда число запросов к этому файлу растет отдача начинает тормозить.
Поместить файлы в виртуальную fs значит максимально ускорить процесс чтения/записи и убрать «узкое горлышко» скорость работы механической части вашего сервера.
ололо, все еще монтируете файловые системы без noatime? тогда тормоза идут к вам.
Совет хороший, только если вы настраиваете фронтенд ремблера.
Для большинства это экономия на спичках.
Совет хороший, только если вы настраиваете фронтенд ремблера.
Для большинства это экономия на спичках.
Можно монтировать ФС с атрибутом noatime, тогда access time не будет записываться. А файловые операции будут кешироваться средствами ОС. Таким образом количество обращений к жёсткому диску за статичным контентом будет минимально, если, конечно, оперативной памяти достаточно.
>Поместить файлы в виртуальную fs значит максимально ускорить процесс чтения/записи и убрать «узкое горлышко» скорость работы механической части вашего сервера.
а так же забрать у себя оперативки по размеру этих файлов. если с оперативкой проблем н бывает, то это нормально, а если ее не так уж много то это может выйти боком когда этот рамдиск засвопируется.
про noatime уже сказали.
а так же забрать у себя оперативки по размеру этих файлов. если с оперативкой проблем н бывает, то это нормально, а если ее не так уж много то это может выйти боком когда этот рамдиск засвопируется.
про noatime уже сказали.
Скажите, а нафига в этой схеме нужен Apache?
Это как мешочки с грузом на воздушном шаре :)
Ну, а если серьёзнее. Меня тоже интересует этот вопрос. Почему именно Apache+nginx? В чём преимущество?
в апаче хорошо работают реврайты (стало ли у nginx лучше, пока не знаю), к тому же они просто правятся в .htaccess,
в остальном преимуществ не вижу
в остальном преимуществ не вижу
В nginx с самого начала rewrite работал лучше и устроен он более логично.
Зато в nginx их куда проще писать, имхо. Если, конечно научиться их готовить ;)
На нагруженных проектах включать AllowOverride лично я не рекомендую, иначе при каждом обращении к файлу, апач на пути к нему будет проверять наличие .htaccess, его синтаксис, что делать из этих правил — пускать ли дальше или нет, юзать ли реврайты и какие и т.п. Не знаю, как оно работает, скорее всего кэшируется, но поскольку изменения в .htaccess вступают всилу без перезагрузки, то банальный stat на время модфикации все же делается, а это не есть хорошо.
На нагруженных проектах включать AllowOverride лично я не рекомендую, иначе при каждом обращении к файлу, апач на пути к нему будет проверять наличие .htaccess, его синтаксис, что делать из этих правил — пускать ли дальше или нет, юзать ли реврайты и какие и т.п. Не знаю, как оно работает, скорее всего кэшируется, но поскольку изменения в .htaccess вступают всилу без перезагрузки, то банальный stat на время модфикации все же делается, а это не есть хорошо.
наскольк я помню… nginx это только прослойка между отрядом апачей и ордой юзеров. и отдает он уже статический контент полученый от апача и кэширует его для следующего клиента.
P.S.
да у меня не получилось юзать nginx как полноценный вэбсервер, я использую связку nginx+apache's
P.S.
да у меня не получилось юзать nginx как полноценный вэбсервер, я использую связку nginx+apache's
Вы неправильно помните. Nginx — полноценный веб-сервер.
я перевалил все на нгикс, уже при первом запуске было ясно, что 14-15 запросов в сек и 22-24 запроса у нгикс против апача. уже дает основания попробывать его на своих проектах. а кеширование контанта это прекрастная функция, которая позволит даже с небольшим ддосом справится
В статье не указано, но вероятно проблема в РНР и необходимости его запуска в режиме FastCGI, если обходиться полностью без Апача. А правильная настройка PHP FastCGI — это уже отдельная история, которую автор, надеюсь поведает нам в ближайшее время :)
нафинг интрестин. гораздо более полезные советы были в выступлении Сысоева на хайлоаде. а тут типа «тюнингуем», собрали с тучей жирных модулей, статистику рисуем как у апача и аще… и вот имеем, nginx в хач-тюнинге. заебись. всем аплодисменты.
Спасибо, добавил в закладки.
Открываю эту статью, а мне…
500 — Internal Server Error
nginx
:)
500 — Internal Server Error
nginx
:)
Извините за грамматический нацизм, но:
>и расплываемся в улибке
>и расплываемся в улибке
Вместо $request "$status" должно быть "$request" $status.
Это соответствует предопределённому формату «combined».
Это соответствует предопределённому формату «combined».
В букмарки!
на боевом сервере подкорректировал свой конфиг, правда там еще и нагрузкой не пахло… но вдруг :)
на боевом сервере подкорректировал свой конфиг, правда там еще и нагрузкой не пахло… но вдруг :)
Интересует работа с виртуальным диском.
У Вас есть какие-нибудь тесты на эту тему или просто кажется, что при откусывании Гига памяти вся система в целом будет работать быстрее?
Почему Вы думаете, что рамдиск будет эфективнее, чем просто системный кэш?
У Вас есть какие-нибудь тесты на эту тему или просто кажется, что при откусывании Гига памяти вся система в целом будет работать быстрее?
Почему Вы думаете, что рамдиск будет эфективнее, чем просто системный кэш?
Гиг взят для примера, можно хоть 16k выделить если вашей статике хватает.
По поводу системного кеша вы можете провести эксперимент c Apache Benchmark, настройте 2 конфигурации nginx одна на tmpfs другая на винт, поставте большое число конкуриющих запросов и тогда разница будет хорошо заметна.
По поводу системного кеша вы можете провести эксперимент c Apache Benchmark, настройте 2 конфигурации nginx одна на tmpfs другая на винт, поставте большое число конкуриющих запросов и тогда разница будет хорошо заметна.
Приведите тесты, я сколько не тестил, нет никакой разницы.
Наверное потому, что её и не должно быть, ведь в обоих случаях запись и чтение идёт через виртуальную память.
Наверное потому, что её и не должно быть, ведь в обоих случаях запись и чтение идёт через виртуальную память.
Разница есть.
Похоже sendfile() работает быстрее с обычной ext3, чем через tmpfs :)
см. результаты выше.
Похоже sendfile() работает быстрее с обычной ext3, чем через tmpfs :)
см. результаты выше.
Я решил провести тесты. Для того чтоб эксперимент можно было считать более-менее чистым отключил iptables, запросы производил с localhost, чтоб исключить влияние пропускного канала, sendfile был включен, тестировал на fs: ext3(у меня небыло возможности подмонтировать диск с noatime), tmpfs
Результат для запроса одиночного файла небольших размеров — разницы практически нет.
ab -n 10000 -c 1000 localhost:8080/vrt/1.jpg
Document Path: /vrt/1.jpg
Document Length: 238482 bytes
Time taken for tests: 6.466 seconds
ab -n 10000 -c 1000 localhost:8080/hdd/1.jpg
Document Path: /hdd/1.jpg
Document Length: 238482 bytes
Time taken for tests: 6.701 seconds
Вы были правы — вношу правки в статью.
Результат для запроса одиночного файла небольших размеров — разницы практически нет.
ab -n 10000 -c 1000 localhost:8080/vrt/1.jpg
Document Path: /vrt/1.jpg
Document Length: 238482 bytes
Time taken for tests: 6.466 seconds
ab -n 10000 -c 1000 localhost:8080/hdd/1.jpg
Document Path: /hdd/1.jpg
Document Length: 238482 bytes
Time taken for tests: 6.701 seconds
Вы были правы — вношу правки в статью.
Тесты показали, что чтение с ext3 быстрее, чем с tmpfs :)
5700 запросов/сек против 5000.
Я извиняюсь за бестактный вопрос, а как насчет noatime?
5700 запросов/сек против 5000.
Я извиняюсь за бестактный вопрос, а как насчет noatime?
У меня не получается воспроизвести.
atime тоже проблема не большая, ведь физическая запись будет происходить не каждый раз, а раз в n минут.
atime тоже проблема не большая, ведь физическая запись будет происходить не каждый раз, а раз в n минут.
atime это просто модификация еще одной страницы дополнительно.
Конечно, я тестил на небольших файлах, и здесь sendfile() отдающий страницу из PAGE_CACHE работает практически одинаково для рассматриваемых fs, а вот дополнительный оверхед на разбор директория и записи туда тоже сказывается видимо.
Понятно, что мой пример, скорее притянутый за уши, чем реальный. Но это просто иллюстрация, что с кэшами всё вовсе не так просто, и не всегда можно спрогнозировать всё в общем случае.
Выиграв единицы процентов в производительности за счет прелоада файлов в рам можно поплатиться значительно раньше начинающимся свапом. А тогда производительность падает в разы.
Конечно, я тестил на небольших файлах, и здесь sendfile() отдающий страницу из PAGE_CACHE работает практически одинаково для рассматриваемых fs, а вот дополнительный оверхед на разбор директория и записи туда тоже сказывается видимо.
Понятно, что мой пример, скорее притянутый за уши, чем реальный. Но это просто иллюстрация, что с кэшами всё вовсе не так просто, и не всегда можно спрогнозировать всё в общем случае.
Выиграв единицы процентов в производительности за счет прелоада файлов в рам можно поплатиться значительно раньше начинающимся свапом. А тогда производительность падает в разы.
tmpfs НЕ откусывает память. она будет использована по мере потребления, в том числе и из свопа.
Да самом деле хороший трюк, особенно если речь идет о mysql, который обожает сортировать некоторые виды запросов на диске. Но вот для nginx как-то мало смысла.
Да самом деле хороший трюк, особенно если речь идет о mysql, который обожает сортировать некоторые виды запросов на диске. Но вот для nginx как-то мало смысла.
Да, я насчёт гигабайта не так выразился, просто какой смысл выделять гигабайт и не использовать его.
Надо сказать, что tmpfs использует то же PAGE_CACHE, что и остальные, т.е. при интенсивной работе с файлами они так и так попадут в этот самый кэш. Разница в том, что «прелоад» чего-то в РАМ далеко не во всех случаях будет давать прирост производительности.
Так как высвопление, например, страниц с кодом может вызвать большие тормоза.
Понятно, что хитрость с RAMDRIVE.SYS нам известна еще со времён дискет на 360к, но в данном случае стоит всё рассматривать комплексно и с замерами. Как я уже показал выше тривиальный noatime может изменить ситуацию до наоборот. А разнесение данных по разным шпинделям может повляить еще больше.
Надо сказать, что tmpfs использует то же PAGE_CACHE, что и остальные, т.е. при интенсивной работе с файлами они так и так попадут в этот самый кэш. Разница в том, что «прелоад» чего-то в РАМ далеко не во всех случаях будет давать прирост производительности.
Так как высвопление, например, страниц с кодом может вызвать большие тормоза.
Понятно, что хитрость с RAMDRIVE.SYS нам известна еще со времён дискет на 360к, но в данном случае стоит всё рассматривать комплексно и с замерами. Как я уже показал выше тривиальный noatime может изменить ситуацию до наоборот. А разнесение данных по разным шпинделям может повляить еще больше.
Ещё можно добавить по поводу мониторинга подключений. Это будет полезно при отслеживании активности пользователей и для сбора статистики по работе nginx.
Для этого включаем stub_status on; как описано в статье, затем ставим вот эту вещь — www.nginx.eu/nginx-rrd.html
Можно настроить мониторинг статуса с удалённого сервера, мониторить можно сразу несколько серверов.
Также есть похожие плагины для Munin —
munin.projects.linpro.no/browser/trunk/node/node.d/nginx_status.in?rev=1740
munin.projects.linpro.no/browser/trunk/node/node.d/nginx_request.in?rev=1740
Для этого включаем stub_status on; как описано в статье, затем ставим вот эту вещь — www.nginx.eu/nginx-rrd.html
Можно настроить мониторинг статуса с удалённого сервера, мониторить можно сразу несколько серверов.
Также есть похожие плагины для Munin —
munin.projects.linpro.no/browser/trunk/node/node.d/nginx_status.in?rev=1740
munin.projects.linpro.no/browser/trunk/node/node.d/nginx_request.in?rev=1740
Раздел где лежит статика можно монтировать с noatime раз уж даже логи там вырубаете для неё
мне всегда казалось, что перед тем как что-либо тюнинговать надо провести профайлинг и посмотреть что именно тормозит.
как у nginx дела с детальным профайлингом? а как насчет профайлинга на боеом сервере под нагрузкой?
как у nginx дела с детальным профайлингом? а как насчет профайлинга на боеом сервере под нагрузкой?
>>Виртуальный диск.
Создаем виртуальный диск (tmpfs), папки js, css, images (если там небольшой обем картинок относящийся к дизайну а не контент)
Вы это сами придумали или кто подсказал?
Создаем виртуальный диск (tmpfs), папки js, css, images (если там небольшой обем картинок относящийся к дизайну а не контент)
Вы это сами придумали или кто подсказал?
UFO just landed and posted this here
Не далее, чем вчера слово «nginx» намозолило мне глаза, выдавая то error 500, то error 502 при заходе на Хабр.
Сегодня захожу — и первое, что мне бросается в глаза — «Тюнинг nginx».
Я волнуюсь…
Сегодня захожу — и первое, что мне бросается в глаза — «Тюнинг nginx».
Я волнуюсь…
а «волшебные пузырьки»?
использование epoll/kqueue (linux/freebsd) в директиве events, сказывается на производительности?
использование epoll/kqueue (linux/freebsd) в директиве events, сказывается на производительности?
спасибо.
gzip -c -9 -n
жмет немного лучше, чем
gzip -c -9
за счет исключения имени файла :)
жмет немного лучше, чем
gzip -c -9
за счет исключения имени файла :)
Про open_file_cache — не рекомендую включать эти опции, если на сервере происходят периодические изменения файлов (вручную или программно — неважно), которые подключаются через SSI. Дело в том, что nginx перестаёт проверять размер файла, т.к. держит в памяти эту информацию, в результате происходит полный беспредел с версткой — файлы считываются не полностью и т.д. — долго в своё время не могли понять, почему див-ы местами менялись в некоторых местах, пока не поняли причину :)
Про tmpfs Игорь Сысоев ответил вопросом «Какую версию MSDOS используете?» =)
forum.nginx.org/read.php?21,16694,16930
tmpfs бестолковое занятие.
Я бы советовал не искать, что бы такого закэшировать, а отрубал бы то, что кэшировать не стоит, дабы в кэш не ротировать. Обычно это длинные файлы, я у себя не кэширую файлы больше 128 килобайт (directio 128k;).
Отключение модулей при компиляции это смешно =) Просто не включать их в конфиге не пробовали? Если не пробовали, попробуйте, можете заодно померять, сколько памяти тратится в обоих случаях. Это забивание гвоздей микроскопом, тратить время своё и читателей на такую ерунду.
Про proxy_store и очистку по крону странная тема. Не эффективнее ли было бы использовать proxy_cache*? Там всё намного веселее во всех отношениях, чем костыли с плясками вокруг cron. Вы же сами про это написали через два пункта после proxy_store.
forum.nginx.org/read.php?21,16694,16930
tmpfs бестолковое занятие.
Я бы советовал не искать, что бы такого закэшировать, а отрубал бы то, что кэшировать не стоит, дабы в кэш не ротировать. Обычно это длинные файлы, я у себя не кэширую файлы больше 128 килобайт (directio 128k;).
Отключение модулей при компиляции это смешно =) Просто не включать их в конфиге не пробовали? Если не пробовали, попробуйте, можете заодно померять, сколько памяти тратится в обоих случаях. Это забивание гвоздей микроскопом, тратить время своё и читателей на такую ерунду.
Про proxy_store и очистку по крону странная тема. Не эффективнее ли было бы использовать proxy_cache*? Там всё намного веселее во всех отношениях, чем костыли с плясками вокруг cron. Вы же сами про это написали через два пункта после proxy_store.
вместо mod_rpaf можно использовать mod_extract_forwarded, который есть собранный в репозитариях федоры
ВНИМАНИЕ!
Sendfile вызывает проблемы внутри VirtualBox'а при работе с общими (shared) папками с хостовой системы. Как в апаче, так и в nginx.
forums.virtualbox.org/viewtopic.php?f=3&t=33201
Sendfile вызывает проблемы внутри VirtualBox'а при работе с общими (shared) папками с хостовой системы. Как в апаче, так и в nginx.
forums.virtualbox.org/viewtopic.php?f=3&t=33201
Sign up to leave a comment.
Тюнинг nginx