Разработчик
27,2
рейтинг
6 апреля 2009 в 10:59

Администрирование → Тюнинг nginx

Статья написана по материалам моего доклада на CodeCamp 2009.

Для многих из нас настает тот долгожданный день, когда аудитория сайта начинает стремительно расти. Каждое утро мы, затая дыхание, смотрим на графики google analitycs и расплываемся в улыбке, когда взят рубеж в очередную тысячу посетителей в день. Как правило, рост посещаемости не совпадает с ростом технической базы и сайт начинает тормозить. Тут в игру вступает сисадмин...

У любого проекта всегда есть что оптимизировать: можно почитать советы по оптимизации на webo.in, установить eaccelerator, memcache, проиндексировать поисковые поля в базе данных. Я предполагаю, что все это уже проделано, а сайт по прежнему тормозит.

Пришло время оптимизировать nginx...


Компиляция nginx


При сборке я обычно руководствуюсь правилом: «отключаю все что не использую». Итак, редко-используемые модули, которые, возможно, вам не пригодятся: mail, mail_ssl_module, http_perl_module, http_flv_module, http_dav_module. Если в будущем некоторое мз модулей будут востребованы, то на перекомпиляцию уйдет несколько минут.

Модули, которые желательно включить при компиляции: http_gzip_static_module, http_stub_status_module.

Вот как выглядит часть моего spec-файла для компиляции nginx (%nginx_datadir,… переменные spec-файла):

./configure \
--prefix=%nginx_datadir \
--conf-path=%nginx_etc/nginx.conf \
--sbin-path=%{_sbindir}/%{name} \
--error-log-path=%nginx_log/nginx.error.log \
--http-log-path=%nginx_log/nginx.log \
--http-client-body-temp-path=%nginx_spool/tmp/client \
--http-proxy-temp-path=%nginx_spool/tmp/proxy \
--http-fastcgi-temp-path=%nginx_spool/tmp/fastcgi \
--pid-path=%_var/run/nginx.pid \
--user=%nginx_user \
--group=%nginx_group \
--with-cc-opt="-I %_includedir/pcre/" \
--with-http_ssl_module \
--with-http_realip_module \
--with-http_addition_module \
--with-http_sub_module \
--with-http_dav_module \
--with-http_flv_module \
--with-http_gzip_static_module \
--with-http_stub_status_module \
--with-http_perl_module 



Конфиг nginx — просто и понятно


Nginx писал админ для админов. Этот факт положительно отразился на синтаксисе конфигов, а также на простоте настройки.
Набросаем простенький конфиг и разберем его директивы:
user nginx;

# Число рабочих процессов, рекомендуется ставить по количеству ядер
worker_processes 8;

# Уменьшает число системных вызовов gettimeofday(), что приводит к увеличению производительности
timer_resolution 100ms;

# Изменяет ограничение на число используемых файлов RLIMIT_NOFILE для рабочего процесса.
worker_rlimit_nofile 8192;

# Директива задаёт приоритет рабочих процессов от -20 до 20 (отрицательное число означает более высокий приоритет). 
worker_priority -5;

error_log /var/log/nginx/error.log;

pid /var/run/nginx.pid;

events {
  worker_connections 2048;
  # use kqueue; для freebsd (рекомендация от )
  use epoll;
}

http {
  include /etc/nginx/mime.types;
  default_type application/octet-stream;


  log_format main '$remote_addr - $remote_user [$time_local] $request '
  '"$status" $body_bytes_sent "$http_referer" '
  '"$http_user_agent" "$http_x_forwarded_for"';

  access_log /var/log/nginx/access.log main;

  # Включить sendfile(). Использование sendfile() экономит системные вызовы, уменьшает число копирований данных, 
  # позволяет использовать меньше физической памяти.
  sendfile on;
  keepalive_timeout 65;

  gzip on;
  gzip_min_length 1100;
  gzip_buffers 64 8k;
  gzip_comp_level 3;
  gzip_http_version 1.1;
  gzip_proxied any;
  gzip_types text/plain application/xml application/x-javascript text/css;

  # Load config files from the /etc/nginx/conf.vs directory
  include /etc/nginx/conf.vs/*.conf;
}


Пример простейшей конфигурации виртуального сервера:
server {
  listen 80;
  server_name _;

  location / {
    gzip_static on;
    root /var/nginx/html;
    index index.html index.htm;
  }

  error_page 404 /404.html;
  location = /404.html {
    root /var/nginx/html;
  }

  error_page 500 502 503 504 /50x.html;
  location = /50x.html {
    root /var/nginx/html;
  }
}

Некоторые директивы я прокоментировал, некоторые мы рассмотрим позже. Главное, на что следует обратить внимание, что синтаксис понятен в большинстве случаев даже без документации.


Мониторинг сервера nginx


В конфиге nginx прописывам секцию
  location = /stat {
    stub_status on;
    access_log  off;
    allow xx.xx.xx.xx;
    deny all;
  }

теперь статистику работы nginx можно смотреть по адресу http://simple.com/stat

Для удобства также желательно настроить статистику для apache, который размещен за nginx. Для этого вначале доустанавливаем модуль mod_rpaf, который позволяет apache «видеть» IP-адреса клиентов, а не IP nginx (здесь можно скачать и скомпилировать мой вариант rpaf srpm), в конфиг apache добавляем:
LoadModule rpaf_module modules/mod_rpaf-2.0.so

#
# Mod rpaf
#

RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1 xx.xx.xx.xx
RPAFheader X-Forwarded-For

Есть альтернативный модуль mod_extract_forwarded, который обеспечивает аналогичную функциональность (есть в репозитории Fedora). (Спасибо Timosha)

Подключаем модуль просмотра статистики:
ExtendedStatus On

SetHandler server-status
Deny from all
Allow from xx.xx.xx.xx
теперь статистику для apache можно смотреть по адресу http://simple.com/apache-stat


Типы статического контента


Статику я условно делю на 2 категории:
«Легкий» контент: html, css, js, xml, rss, txt. Он хорошо поддается сжатию, требует мало места для хранения. Приминение nginx в любом случае даст заметный прирост производительности.
«Тяжелый» контент: фото, видео, аудио-файлы. Узким местом выступает, в первую очередь дисковая система, размер оперативной памяти, пропускная способность канала. Задача раздачи такого типа контента делится на 2 — хранение контента и, собственно, раздача контента. С помощью nginx можно добиться минимального расхода памяти и процессорного времени, но при увеличении нагрузки все же прийдется собирать RAID-масив.

Что делать когда сайт начинает тормозить


Ну во первых не паниковать. Возможно именно в этот момент к вашему сайту приходит популярность :)
Как правило тормозит не nginx а бекенд (сервер который генерит динамический контент) или, как часто бывает, сервер БД, место на дисках кончилось, запустился супер-пупер анализатор чеого-то и загреб все ресурсы,…
В рамках этой статьи мы рассмотрим тот случай когда вы подозреваете именно nginx. Что же можно подкрутить, чтоб временно облегчить страдания сервера?
  1. Попробуйте увеличить количество worker_processes, автор nginx советует устанавливать их по количеству ядер. Я варьировал это количество приблизительно в диапазоне «количество ядер» — «количество ядер x 2», при этом добивался более быстрого установление соедиенения, но не всегда более оперативной обработки http-запроса. Не забудьте, что есть еще worker_connections (максимальное количество конекшинов для одного worker)
  2. Поможет установка worker_priority в -5 и меньше (до -20). Тут будьте осторожны, так как другие сервисы могут начать заметно тормозить. На наших серверах этот параметрт установлен в -5. Чем меньше значение — тем выше приоритет для nginx
  3. При большом количестве отдачи мелких файлов и медленном винчестере может помочь временное отключение логов access_log off.
  4. UPD: Смонтируйте диск, с которого идет раздача с опцией noatime, это уменьшит количество операций записи на диск. (Спасибо за идею coolspot, pwlnw, alfa)
  5. Ищите узкое место, может его можно устранить. Вам помогут комманды: top, iostat, df -h, iptraf
  6. Добавьте оперативной памяти или усовершенствуйте дисковую систему (например установите RAID-масив, можно поэкспериментировать с SSD-винчестером)



Приемы оптимизации


«Легкий» контент

  1. Виртуальный диск.
    Создаем виртуальный диск (tmpfs или ramfs), папки js, css, images (если там небольшой обем картинок относящийся к дизайну а не контент) переносим туда и в конфиге nginx, отдельно прописываем
    location /js/ {
    root /var/www/img_virtual/auto.ria.ua/js
    }
    ...
    Для того, чтоб виртуальный диск создавался автоматически при перезагрузке в /etc/fstab добавляем
    none /var/www/img_virtual tmpfs size=1g,mode=1777 0 0
    (при старте системы автоматически будет создаваться диск, размером 1G)
    Тут следует обратить внимание на следующее обстоятельство: если статический файл попадает в системный кеш, то скорость его отдачи с системного кеша равняется скорости отдачи с виртуального диска. Другими словами если общее количество всей раздаваемой «легкой» статики небольшое, то надобность в виртуальном диске отпадает (Спасибо maxp за то что побудил меня провести тесты и убедится в этом)
  2. Сжатие контента gzip-ом
    Запускаем в нашей виртуальной папке
    for i in `find ./* -type f -name '*.js'`; do echo $i; gzip -c -9 $i > $i.gz; done;
    for i in `find ./* -type f -name '*.css'`; do echo $i; gzip -c -9 $i > $i.gz; done;
    в конфиг nginx добавляем строчку gzip_static on:
    location /js/ {
    gzip_static on;
    root /var/www/img_virtual/auto.ria.ua/js
    }
    Также можно включить online упаковку для динамических файлов:
    location / {
    gzip on;
    gzip_min_length 1100;
    gzip_buffers 16 8k;
    gzip_comp_level 3;
    gzip_types text/plain application/xml application/x-javascript text/css;

    root /var/www/auto.ria.ua/
    }
  3. Заголовки для проксирования контента
    Указание в заголовках времени жизни статического контента также приведет к уменьшению нагрузки. Для этого будем использовать директиву expires. Если контент не будет меняться, со вренем можно использовать expires max. Даже expires 1d даст хороший результат
  4. Кеширование дескрипторов файлов
    Это даст прирост производительности, если у вас множество мелких файлов с развернутой иерархией директорий. Также можно закешировать обращение к несуществующим файлам. Выглядеть это будет приблизительно так:
    location / {
    root /var/www/;


    open_file_cache max=1024 inactive=600s;
    open_file_cache_valid 2000s;
    open_file_cache_min_uses 1;
    open_file_cache_errors on;
    }

«Тяжелый» контент

  1. Вначале надо обратить внимание на то, не используется ли swap при отдаче контента, если да то это может быть проблемой, если swap находится на обычном SATA-винчестере. Свопиться любит metod ядра "sendfile", это безусловно прогрессивная технология, но использование swap будет существенно влиять на отдачу и тогда попробуйте sendfile отключить директивой sendfile off и подберите оптимальное заначение для output_buffers, например output_buffers 2 64k;
    Пример настройки с выключеным sendfile:
    sendfile off;
    tcp_nodelay on;
    output_buffers 2 64k;
    Обращаю ваше внимание на то, что многое будет зависеть от ядра, используемого системой, мне это помогло на ядрах >= 2.6.27.
  2. Если позволяет оперативная память, создайте виртуальный диск, на который поместите самые «запрашиваемые» файлы, со временем, скажем, раз в 10 минут вы можете корректировать список этих файлов. Теперь мы можем применить директиву try_files:
    location / {
    root /var/www/;
    try_files /img_virtual/hot/$uri storage;
    }

    location storage {
    proxy_pass http://backend;
    proxy_set_header Host $host;
    }
    Если файл не будет найден, на виртуальном диске будет обращение к backend.

    Как правило «горячий контент» составляет менее 10% от общего объема.

    Если свою программу по формированию кеша писать нет возможности, используйте директиву proxy_store
    location storage {
    proxy_pass http://backend;
    proxy_set_header Host $host;

    proxy_store on;
    proxy_store_access user:rw group:rw all:r;
    proxy_temp_path /var/www/img_virtual/hot/;
    root /var/www/img_virtual/hot/;
    }
    При такой конфигурации каждый запрошеный файл помещается в кеш.
    Со временем кеш надо как-то чистить, самый простой способ запускать на кроне:
    cd /var/www/img_virtual/hot/
    find ./ -type f -amin +60 -delete
    (если файл из кеша не запрашимвается более 60 минут, мы его удаляем)
  3. Если storage большой, занимает терабайты — оперативой вопрос не решить. Можно на фронтенд-е собрать RAID. Не советую использовать fake-raid, это головная боль при апгрейде и при пропадании света! Берем побольше винтов SAS, берем полноценный RAID-котроллер (никаких hostraid!). Монтируем туда swap, spool и кеш.Для нечасто меняющегося контента и нечастой перезаписи кеша можно применять SSD-винчестеры. Это работает быстро, у таких винчестеров нет такой характеристики как seek-to-seek, малый расход энергии (например для Intel X25-M 0,15Вт), хорошая скорость отдачи (до 250 MB/s).
  4. Кеширование проксированых запросов.
    23 марта 2009 года вышла очередная бета nginx 0.7.44, в которой появилась экспериментальная поддержка кеширования проксированных запросов. Трудно переоценить важность этого события для пользователей nginx. Автор nginx вручает нам мощный инструмент в управлении раздачи большого объема статики.
    Почему нужен такой кеш? Ответ на этот вопрос главным образом связан с разной «стоимостью» дисковой операции и сетевой операции. «Сходить» на диск во многих случаях значительно «дешевле», чем обращение в сеть. Главная задача такого кеширования сводится к сведению к необходимому минимуму сетевых операций и «интелектуальному управлению» дисковым кешем.
    Подробнее о настройки кеша проксированных запросов.
Олег Черний @apelsyn
карма
171,1
рейтинг 27,2
Разработчик
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

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

  • +1
    Спасибо, очень полезные советы.
  • 0
    Насчет рекомендации использовать SSD под не часто меняющийся контент (но он в люббом случае меняется, хоть и очень медленно) проверенно на личном опыте? Или просто — жертва маркейтинга?
    (Много где читал что SSD со временем начинают ужасно тормазить, или уже пофиксено?)
    • 0
      Тормозят даже на чтении? Если так, то у них-таки есть seek-to-seek
      • 0
        Но даже если и тормозят, то все равно должен быть выигрыш, особенно на мелких файлах т.к. время доступа более критично чем линейная скорость чтения.
        Самому бы пощупать.
    • 0
      4 SSD самсунга в RAID-е, если на него замонтировать /var/lib/mysql жывут 4 месяца потом сыпятся все одновременно (эта инфа из опыта моего знакомого, который провел експеримент на одном из хостинг-серверов). Я советую посмотреть в сторону SSD Intel x25m он только недавно поступил в продажу, этот должен выдержать.
      • 0
        Думаю, что флешки еще не доросли до того уровня, когда на них можно вести активную перезапись.
  • 0
    Хороший материал, что ещё сказать.
  • 0
    Для того, чтоб виртуальный диск создавался автоматически при перезагрузке в /etc/fstab добавляем
    none /var/www/img_virtual tmpfs size=1g,mode=1777 0 0


    а откуда там возьмутся эти статические файлы? :)
    • 0
      Очевидно, что туда их нужно скопировать :).

      Я обычно делаю сабдомены:
      /var/www/img_virtual/img.hostname1
      /var/www/img_virtual/img.hostname2

      и вытягиваю из svn репозитория туда только папки /js, /css, /img соответствующего проекта

      В теплейтах пишу полный путь img.hostname1/img/picture.jpg.

      Как оказалось эти папки занимают очень мало места.

      Мне, в определенный момент, все это сильно помогло.
      • 0
        А Вы можете объяснить, почему Вам помогло использование tmpfs?
        Мне не понятно, зачем советуют tmpfs для статики.
        • 0
          nginx при отдаче любого файла производит запись и чтение на диск. Да-да запись тоже производит, например апдейтит last access time!

          При небольшом числе запросов с этим неплохо справляется обычный винчестер, когда число запросов к этому файлу растет отдача начинает тормозить.

          Поместить файлы в виртуальную fs значит максимально ускорить процесс чтения/записи и убрать «узкое горлышко» скорость работы механической части вашего сервера.
          • +1
            ололо, все еще монтируете файловые системы без noatime? тогда тормоза идут к вам.
            Совет хороший, только если вы настраиваете фронтенд ремблера.
            Для большинства это экономия на спичках.
          • 0
            Можно монтировать ФС с атрибутом noatime, тогда access time не будет записываться. А файловые операции будут кешироваться средствами ОС. Таким образом количество обращений к жёсткому диску за статичным контентом будет минимально, если, конечно, оперативной памяти достаточно.
            • +1
              Тут я с Вами соглашусь, действительно noatime ускорит работу файловой системы.

              Добавлю еще один пункт в статью.
          • 0
            >Поместить файлы в виртуальную fs значит максимально ускорить процесс чтения/записи и убрать «узкое горлышко» скорость работы механической части вашего сервера.

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

            про noatime уже сказали.
  • 0
    Скажите, а нафига в этой схеме нужен Apache?
    • +2
      Это как мешочки с грузом на воздушном шаре :)
      • 0
        Ну, а если серьёзнее. Меня тоже интересует этот вопрос. Почему именно Apache+nginx? В чём преимущество?
        • 0
          в апаче хорошо работают реврайты (стало ли у nginx лучше, пока не знаю), к тому же они просто правятся в .htaccess,
          в остальном преимуществ не вижу
          • 0
            В nginx с самого начала rewrite работал лучше и устроен он более логично.
          • 0
            Зато в nginx их куда проще писать, имхо. Если, конечно научиться их готовить ;)

            На нагруженных проектах включать AllowOverride лично я не рекомендую, иначе при каждом обращении к файлу, апач на пути к нему будет проверять наличие .htaccess, его синтаксис, что делать из этих правил — пускать ли дальше или нет, юзать ли реврайты и какие и т.п. Не знаю, как оно работает, скорее всего кэшируется, но поскольку изменения в .htaccess вступают всилу без перезагрузки, то банальный stat на время модфикации все же делается, а это не есть хорошо.
            • 0
              У Apache ещё потомки мрут (если специально ничего не сделать, а если сделать — потечёт), так что кеш умирает вместе с потомком.
    • 0
      наскольк я помню… nginx это только прослойка между отрядом апачей и ордой юзеров. и отдает он уже статический контент полученый от апача и кэширует его для следующего клиента.
      P.S.
      да у меня не получилось юзать nginx как полноценный вэбсервер, я использую связку nginx+apache's
      • +4
        Вы неправильно помните. Nginx — полноценный веб-сервер.
      • 0
        я перевалил все на нгикс, уже при первом запуске было ясно, что 14-15 запросов в сек и 22-24 запроса у нгикс против апача. уже дает основания попробывать его на своих проектах. а кеширование контанта это прекрастная функция, которая позволит даже с небольшим ддосом справится
    • –1
      В статье не указано, но вероятно проблема в РНР и необходимости его запуска в режиме FastCGI, если обходиться полностью без Апача. А правильная настройка PHP FastCGI — это уже отдельная история, которую автор, надеюсь поведает нам в ближайшее время :)
      • +2
        настройка PHP в режиме FastCGI — это очень просто. Я пробовал 3 способа и все они очень простые.
  • –1
    нафинг интрестин. гораздо более полезные советы были в выступлении Сысоева на хайлоаде. а тут типа «тюнингуем», собрали с тучей жирных модулей, статистику рисуем как у апача и аще… и вот имеем, nginx в хач-тюнинге. заебись. всем аплодисменты.
  • 0
    Спасибо, добавил в закладки.
  • +4
    Открываю эту статью, а мне…

    500 — Internal Server Error
    nginx

    :)
    • +1
      Ага, то же самое :)
    • +2
      Ага. Ждем пока админы хабра прочтут статью :))
    • +1
      Не говорите-через раз, то 500, то 502.
    • +1
      Дык админы в этот момент тюнинговали nginx, вдохновившись статьей :)
  • +1
    Извините за грамматический нацизм, но:
    >и расплываемся в улибке
    • 0
      в копилку опечаток

      >минимуму сетевых опрераций
    • 0
      поправил, спасибо.
      • 0
        «Статья написана по матерриалам»
  • 0
    Вместо $request "$status" должно быть "$request" $status.
    Это соответствует предопределённому формату «combined».
  • 0
    В букмарки!

    на боевом сервере подкорректировал свой конфиг, правда там еще и нагрузкой не пахло… но вдруг :)
  • 0
    Интересует работа с виртуальным диском.
    У Вас есть какие-нибудь тесты на эту тему или просто кажется, что при откусывании Гига памяти вся система в целом будет работать быстрее?

    Почему Вы думаете, что рамдиск будет эфективнее, чем просто системный кэш?
    • 0
      Гиг взят для примера, можно хоть 16k выделить если вашей статике хватает.

      По поводу системного кеша вы можете провести эксперимент c Apache Benchmark, настройте 2 конфигурации nginx одна на tmpfs другая на винт, поставте большое число конкуриющих запросов и тогда разница будет хорошо заметна.
      • 0
        Приведите тесты, я сколько не тестил, нет никакой разницы.
        Наверное потому, что её и не должно быть, ведь в обоих случаях запись и чтение идёт через виртуальную память.
        • 0
          Разница есть.
          Похоже sendfile() работает быстрее с обычной ext3, чем через tmpfs :)

          см. результаты выше.
          • 0
            т.е. ниже.
        • 0
          Я решил провести тесты. Для того чтоб эксперимент можно было считать более-менее чистым отключил 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

          Вы были правы — вношу правки в статью.
      • 0
        Тесты показали, что чтение с ext3 быстрее, чем с tmpfs :)
        5700 запросов/сек против 5000.

        Я извиняюсь за бестактный вопрос, а как насчет noatime?
        • 0
          У меня не получается воспроизвести.

          atime тоже проблема не большая, ведь физическая запись будет происходить не каждый раз, а раз в n минут.
          • 0
            atime это просто модификация еще одной страницы дополнительно.

            Конечно, я тестил на небольших файлах, и здесь sendfile() отдающий страницу из PAGE_CACHE работает практически одинаково для рассматриваемых fs, а вот дополнительный оверхед на разбор директория и записи туда тоже сказывается видимо.

            Понятно, что мой пример, скорее притянутый за уши, чем реальный. Но это просто иллюстрация, что с кэшами всё вовсе не так просто, и не всегда можно спрогнозировать всё в общем случае.

            Выиграв единицы процентов в производительности за счет прелоада файлов в рам можно поплатиться значительно раньше начинающимся свапом. А тогда производительность падает в разы.
    • +1
      tmpfs НЕ откусывает память. она будет использована по мере потребления, в том числе и из свопа.
      Да самом деле хороший трюк, особенно если речь идет о mysql, который обожает сортировать некоторые виды запросов на диске. Но вот для nginx как-то мало смысла.
      • 0
        Да, я насчёт гигабайта не так выразился, просто какой смысл выделять гигабайт и не использовать его.

        Надо сказать, что tmpfs использует то же PAGE_CACHE, что и остальные, т.е. при интенсивной работе с файлами они так и так попадут в этот самый кэш. Разница в том, что «прелоад» чего-то в РАМ далеко не во всех случаях будет давать прирост производительности.
        Так как высвопление, например, страниц с кодом может вызвать большие тормоза.

        Понятно, что хитрость с RAMDRIVE.SYS нам известна еще со времён дискет на 360к, но в данном случае стоит всё рассматривать комплексно и с замерами. Как я уже показал выше тривиальный noatime может изменить ситуацию до наоборот. А разнесение данных по разным шпинделям может повляить еще больше.
  • 0
    Ещё можно добавить по поводу мониторинга подключений. Это будет полезно при отслеживании активности пользователей и для сбора статистики по работе 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
  • 0
    Раздел где лежит статика можно монтировать с noatime раз уж даже логи там вырубаете для неё
  • +1
    мне всегда казалось, что перед тем как что-либо тюнинговать надо провести профайлинг и посмотреть что именно тормозит.
    как у nginx дела с детальным профайлингом? а как насчет профайлинга на боеом сервере под нагрузкой?
  • 0
    >>Виртуальный диск.
    Создаем виртуальный диск (tmpfs), папки js, css, images (если там небольшой обем картинок относящийся к дизайну а не контент)

    Вы это сами придумали или кто подсказал?
    • +2
      Ты че такой дерзкий, а?
    • 0
      Не совсем понял, а что собственно с вашей точки зрения не так?
  • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Не далее, чем вчера слово «nginx» намозолило мне глаза, выдавая то error 500, то error 502 при заходе на Хабр.
    Сегодня захожу — и первое, что мне бросается в глаза — «Тюнинг nginx».
    Я волнуюсь…
  • 0
    а «волшебные пузырьки»?
    использование epoll/kqueue (linux/freebsd) в директиве events, сказывается на производительности?
    • 0
      насколько я помню, игорь сысоев отдельно рекомендовал их к использованию на одной из конференций highload
    • 0
      Согласен, добавлю в статью.

      Поддержка этих модулей включается автоматически при сборке, в случае если они поддерживаются системой.
  • 0
    спасибо.
  • 0
    gzip -c -9 -n
    жмет немного лучше, чем
    gzip -c -9
    за счет исключения имени файла :)
  • 0
    Про open_file_cache — не рекомендую включать эти опции, если на сервере происходят периодические изменения файлов (вручную или программно — неважно), которые подключаются через SSI. Дело в том, что nginx перестаёт проверять размер файла, т.к. держит в памяти эту информацию, в результате происходит полный беспредел с версткой — файлы считываются не полностью и т.д. — долго в своё время не могли понять, почему див-ы местами менялись в некоторых местах, пока не поняли причину :)
  • 0
    Про tmpfs Игорь Сысоев ответил вопросом «Какую версию MSDOS используете?» =)
    forum.nginx.org/read.php?21,16694,16930
    tmpfs бестолковое занятие.

    Я бы советовал не искать, что бы такого закэшировать, а отрубал бы то, что кэшировать не стоит, дабы в кэш не ротировать. Обычно это длинные файлы, я у себя не кэширую файлы больше 128 килобайт (directio 128k;).

    Отключение модулей при компиляции это смешно =) Просто не включать их в конфиге не пробовали? Если не пробовали, попробуйте, можете заодно померять, сколько памяти тратится в обоих случаях. Это забивание гвоздей микроскопом, тратить время своё и читателей на такую ерунду.

    Про proxy_store и очистку по крону странная тема. Не эффективнее ли было бы использовать proxy_cache*? Там всё намного веселее во всех отношениях, чем костыли с плясками вокруг cron. Вы же сами про это написали через два пункта после proxy_store.
    • 0
      > Про tmpfs Игорь Сысоев ответил вопросом «Какую версию MSDOS используете?» =)

      Там речь идет о FreeBSD.

      > Это забивание гвоздей микроскопом, тратить время своё и читателей на такую ерунду.

      Вы за читетлей не расписывайтесь, некрасиво как-то.
  • 0
    вместо mod_rpaf можно использовать mod_extract_forwarded, который есть собранный в репозитариях федоры
  • 0
    ВНИМАНИЕ!

    Sendfile вызывает проблемы внутри VirtualBox'а при работе с общими (shared) папками с хостовой системы. Как в апаче, так и в nginx.

    forums.virtualbox.org/viewtopic.php?f=3&t=33201

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