Установка Nginx 1.1 на FreeBSD 8.2

Компилируем:

cd /usr/ports/www/nginx
make install clean

Добавляем в автозапуск:

vi /etc/rc.conf

Добавляем там:

nginx_enable="YES"

Запускаем:

/usr/local/etc/rc.d/nginx start

Отличный модуль для Nginx для кэширования данных не в памяти, а на ssd

http://labs.frickle.com/nginx_ngx_slowfs_cache/

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

Корректная очистка Nginx кэша

Достаточно лишь удалить файлы кэша:

find /var/lib/nginx/cache -type f -exec rm {} \;

Либо вот так:

for i in `find /var/lib/nginx/cache -type f`; do rm $i ; done

Источник: http://forum.nginx.org/read.php?2,2600,2602

Команда для анализа ключей в содержимом кэша nginx

for i in `find /var/lib/nginx/cache/ -type f`; do cat $i | grep -a KEY; done | sort | uniq

В ответ будет выдан спсиок ключей закэшированных страниц.

Что означает worker process 4664 exited on signal 9?

Вот такая запись означает:

2011/05/31 10:54:38 [alert] 4089#0: worker process 4664 exited on signal 9

Что кто-то убил рабочий процесс Nginx по kill -9:

Posted by Igor Sysoev (Guest) on 2008-07-08 14:10
On Tue, Jul 08, 2008 at 02:55:08PM +0300, Athan Dimoy wrote:

> Just a question according the new build. What this error really means
> "worker process 94184 exited on signal 9"?

This means that someone kills -9 worker process.

Проксирование Confluence посредством Nginx на Debian

Стаивм Nginx:

apt-get install -y nginx

После этого очищаем следующий конфиг:

vi /etc/nginx/sites-enabled/default

И вносим в него следующие строки:

server {
listen 80;
server_name wiki.domain.ru;

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

location / {
proxy_set_header Host $host;
proxy_pass http://127.0.0.1:8180;
}
}

Применяем настройки:

/etc/init.d/nginx restart

Источник: http://serverfault.com/questions/118592/can-i-get-advice-on-my-nginx-configuration-as-a-proxy-in-front-of-jira-and-confl

the "alias" directive may not be used inside location given by regular expression

Это означает, что нужно использовать Nginx версии выше 0.7.40.

Источник: http://nginx.org/pipermail/nginx/2010-July/021280.html

Nginx + memcached = connect() to 127.0.0.1:11211 failed (99: Cannot assign requested address) while connecting to upstream

При нагрузочном тестировании:

ab -c 45 -n 1000000 http://domain.ru/

Вот такая радость в логах Nginx 0.7.65:

2010/12/05 21:54:14 [crit] 21537#0: *14117 connect() to 127.0.0.1:11211 failed (99: Cannot assign requested address) while connecting to upstream, client: xx.xx.xx.xx server: domain.ru, request: "POST /test.php HTTP/1.1", subrequest: "/test.php", upstream: "memcached://127.0.0.1:11211", host: "domain.ru"

Как симптом море TIME_WAIT ов:

netstat -an |grep TIME_WAIT | grep 11211 | wc -l
24203

Фиксить нужно так:

Нужно увеличить число исходящих портов. Как это сделать в Линуксе - не знаю.
--
Игорь Сысоев

Но проблема в том, что пул этих адресов итак огромен:

sysctl -a|grep range
net.ipv4.ip_local_port_range = 32768 61000

Далее идет вот такое обсуждение перенастройки на 1024-65535:

now my benchmark test works fine. are there any other problems
when i run debian with this large port range?

No, there should no be problems.
You may set 1024-65535.

Есть еще вариант:

sysctl -a | grep recycl
net.ipv4.tcp_tw_recycle = 0

sysctl -a | grep reuse
net.ipv4.tcp_tw_reuse = 0

Итого, резюмируя, лично я делаю так (18000 потому, что с 21 по 17900 у меня висят различные демоны):

echo "net.ipv4.ip_local_port_range = 18000 61000" >> /etc/sysctl.conf
sysctl -p

И не забываем перезаупстить Nginx:

/etc/init.d/nginx restart

Итого, мы где-то на 15 000 портов расширили интервал исходящих портов и ошибка должна исчезнуть.

Источник: вот и вот

Nginx, директива post_action, выполнение действий ПОСЛЕ обработки запроса клиента

Вот ссылка с фоурмов: http://article.gmane.org/gmane.comp.web.nginx.english/1305

В офф документации не нашел, но штука крайне интересная.

Набор крутых модулей для Nginx, шикарнейшая презенатция

http://agentzh.org/misc/slides/nginx-conf-scripting/nginx-conf-scripting.html#79

Nginx + memcached = 400% ускорение сайтов!

http://www.igvita.com/2008/02/11/nginx-and-memcached-a-400-boost/

Почему в Nginx нету и не будет поддержки .htaccess?

Вот аргументы: http://wiki.nginx.org/Talk:NginxFeatureRequests

Но, честно говоря, все, кроме п.п. 1 крайне сомнительно и лично мной в упор не принимаемо :)

Nginx и поведение при 503 от бэкэнда

http://www.openg.info/entry/make-nginx-reverse-proxy-503-error-pages-pass-client
и http://wiki.nginx.org/NginxHttpProxyModule#proxy_intercept_errors

[emerg] 3728#0: could not build the server_names_hash, you should increase server_names_hash_bucket_size: 32

Чтобы исправить, делаем следующее:

vi /etc/nginx/nginx.conf

После этого в блок http { } в самый его верх добавляем следующее:

server_names_hash_bucket_size 512;

Перезапускаем Nginx:

/etc/init.d/nginx restart

Вуаля :)

Подробнее: http://wiki.nginx.org/NginxHttpCoreModule#server_names_hash_bucket_size

Nginx как Comet сервер

http://highload.com.ua/index.php/2010/07/21/%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D1%83%D0%B5%D0%BC-nginx-%D0%BA%D0%B0%D0%BA-long-polling-comet-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80/

Активация модуля geo в Nginx 0.7.65

Будем подключать вот это:
http://wiki.nginx.org/NginxHttpGeoModule

Почему именно geo, а не geoip? Вот результаты тестов, проведенных нашими сотрудниками:

С геоип:
средняя для -n1 (10 измерений, каждый запрос с нового адреса): 5.20
средняя для -n10000 -c1: 6.63
Средняя для -n10000 -c10: 55.06
потребление памяти: каждый воркер имеет свою базу geoip (страны - 500 Кб, города - 20 Мб)

C гео:
средняя для -n1 (10 измерений, каждый запрос с нового адреса): 6.61
средняя для -n10000 -c1: 6.73
Средняя для -n10000 -c10: 58.01
потребление памяти: каждый воркер имеет свою базу geoip (только страны - 4 Мб)

Без геоип:
средняя для -n1 (10 измерений, каждый запрос с нового адреса): 6.70
Средняя для -n10000 -c1: 6.76
Средняя для -n10000 -c10: 57.91

Скачиваем файлы с IP адресами:

cd /usr/src
wget http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip
unzip GeoIPCountryCSV.zip

Теперь, даже если у Вас nginx стоит из пакетов стягиваем дистрибутив nginx треубуемой версии:

cd /usr/src
wget http://sysoev.ru/nginx/nginx-0.7.65.tar.gz
tar -xf nginx-0.7.65.tar.gz

Конвертируем geoip файл в формат nginx и переносим в папку nginx:

perl nginx-0.7.65/contrib/geo2nginx.pl < GeoIPCountryWhois.csv > geo.conf
mv geo.conf /etc/nginx/

Подключаем к nginx:

vi /etc/nginx/nginx.conf

Также вниз блока http добавляем следующее:

geo $country {
default no;
include /etc/nginx/geo.conf;
}

Далее изменяем формат логов, чтобы туда также попадала страна клиента:

log_format vhost_ip_full_format '$remote_addr - $remote_user [$time_local] $host $server_addr $request '
'$status $body_bytes_sent "$http_referer"'
'"$http_user_agent" "$http_x_forwarded_for" $request_time-$upstream_response_time "$country"';
access_log /var/log/nginx/access.log vhost_ip_full_format;

Перезапускаем Nginx:

/etc/init.d/nginx reload

Куча сторонних модулей к Nginx

http://wiki.nginx.org/Nginx3rdPartyModules#Catalog_of_Modules

Как запретить Nginx логгировать в error.log "2: No such file or directory"?

http://sysoev.ru/nginx/docs/http/ngx_http_core_module.html#log_not_found

То есть внутрь блока http {} добавляем:

log_not_found off;

И перезапускаем Nginx:

/etc/init.d/nginx reload

После этого весь мусор из логов пропадет в один момент и не будет более терроризировать диск.

Использование Pylons в продакшене: paster + Nginx

Разработку приложения можно вполне вести и на встроенном веб-сервере paster, но как только посещаемость увеличивается и Вы запускаете проект, то, безусловно, paster - не лучший выбор. Тут ем может помочь Nginx, выступающий в качестве reverse proxy!

Итак, имеем paster на 5000 порту:

http://127.0.0.1:5000

Ставим Nginx (здесь и далее - ОС Debian 5 Lenny):

apt-get install -y nginx

Удаляем конфиг стандартного сайта:

rm /etc/nginx/sites-enabled/default

Создаем новый:

vi /etc/nginx/sites-enabled/default

Со следующим содержимым:

server {
listen 80;
server_name domain.ru;

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

location / {
# передаем хостнейм Paster, хотя это не обязательно
proxy_set_header Host $host;
proxy_pass http://127.0.0.1:5000;
}
}

Перезапускаем Nginx и применяем настройки:

/etc/init.d/nginx restart

Следом запускаем paster (иначе поулчим на 80м порту "502 bad gateway"):

cd myapp
nohup paster serve --reload development.ini &

Все, теперь открываем сайт http://domain.ru и любуемся видом нашего Pylons проекта.

Поиск аномальных записей в логах ошибок Nginx и Apache

В логах ошибок Апача и Нгинкса тонны записей, но полезных среди них очень мало и они почти теряются на фоне ошибок "No such directory" и прочих, что делает просмотр логов очень неудобным и допускающим пропуск важных записей. Чтобы просматривать логи в удобном виде, необходимо отфильтровать лишние записи каким-либо образом, например грепом. Все примеры ниже будут для Debian.

Nginx:

cat /var/log/nginx/error.log | grep -v '2: No such file or directory' | grep -v 'failed (20: Not a directory' | grep -v ' access forbidden by rule' | egrep -v 'conflicting server name.*ignored' | grep -v 'Connection refused' | grep -v 'upstream timed out' | grep -v 'Connection reset by peer' | grep -v 'upstream prematurely closed connection while reading response header'

Apache:

cat /var/log/apache2/error.log /var/log/httpd/error_log | grep -v '\[notice\] mod_fcgid: call' | grep -v 'Init: SSL server IP/port conflict' | grep -v 'RSA server certificate wildcard' | grep -v 'suEXEC mechanism enabled' | grep -v 'Init: You should not use name-based virtual hosts in conjunction with SSL' | grep -v 'mod_ssl/2.2.9 OpenSSL/0.9.8g configured -- resuming normal operations' | grep -v 'File does not exist' | grep -v 'RSA server certificate is a CA certificate' | grep -v 'RSA server certificate CommonName ' | grep -v 'Graceful restart requested, doing restart' | grep -v 'caught SIGTERM, shutting down' | grep -v 'Digest: done' | grep -v 'Digest: generating secret for digest authentication' | grep -v 'configured -- resuming normal operations' | grep -v 'Could not reliably determine the server' | egrep -v 'DocumentRoot.*does not exist' | egrep -v 'mod_fcgid: process.*terminated by calling exit\(\), return code: 0' | grep -v 'No such file or directory: Timeout connecting daemon' | grep -v 'process.*going graceful shutdown, sending SIGTERM' | grep -v 'process.*graceful shutdown timeouted, sending SIGKILL' | grep -v 'mod_fcgid: cleanup zombie process' | grep -v 'mod_fcgid: too much' | grep -v 'process.*exit(communication error)' | grep -v 'process.*exit(shutting down)' | grep -v 'Premature end of script headers: ispmgr' | egrep -v 'script.*not found or unable to stat' | grep -v 'client denied by server configuration' | grep -v 'mod_fcgid: process.*exit(lifetime expired)' | grep -v 'mod_fcgid: process.*exit(idle timeout)' | grep -v 'mod_fcgid: process.*exit(busy timeout)'

ISPManager:

cat /usr/local/ispmgr/var/ispmgr.log | grep Error -i | grep -v 'error.log' | grep -v 'location_error' | grep -v 'fdata='

Поиск аномалий по клиентским логам:

for i in `find /var/www/*/data/logs | grep 'error.log'`; do file $i | grep -q 'gzip compressed data'; if [ $? -eq 0 ]; then zcat $i ; else cat $i; fi ; done | grep -v 'File does not exist' | grep -v 'client denied by server configuration' | grep -v 'script not found or unable to stat' | grep -v 'not found or unable to stat' | grep -v 'No such file or directory: Timeout connecting daemon' | grep -v 'File name too long' | grep -v 'Directory index forbidden by Options directive' | grep -v 'attempt to invoke directory as script' | grep -v 'mod_fcgid: server is restarted' | grep -v 'Permission denied: file permissions deny server access' | egrep -v 'script.*not found or unable to stat' | grep -v "Permission denied: Can't open directory for index" | grep -v 'stderr: WordPress database error' | grep -v 'mod_fcgid: read data timeout in 40 seconds' | grep -v 'Premature end of script headers' | grep -v 'Request exceeded the limit of 10 internal redirects'