Добрый день!
У меня ряд серверов раздают большие фильмы и диски изрядно и постоянно
нагружены. Решил воспользоваться двумя советами, чтобы облегчить им жизнь.
Freebsd 6.3 nginx/0.7.21 sendfile on;
для начала пересобрал ядро с MAXPHYS=1024*1024 и поднял kern.ipc.sfreadahead
- заметно полегчало.
параллельно на другом сервере отформатировал винчестеры с блоком 64kb - тоже
появился прирост на 30%, но там не nginx.
Воодушевленный решил скрестить оба метода.
Отформатировал все винчестеры с блоком 64kb и тут случилась засада. nginx в
жестком biord! все тормозит, скорость упала в два раза.
смотрю iostat:
tty ad4 ad6 da0 cpu
tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
0 233 64.00 90 5.62 64.00 54 3.37 280.25 8 2.19 4 0 11 15 70
0 78 64.00 91 5.68 64.00 53 3.31 218.12 16 3.40 3 0 8 20 70
0 78 64.00 85 5.31 64.00 67 4.18 288.00 14 3.25 1 0 13 17
69
0 78 64.00 90 5.62 64.00 62 3.87 189.29 17 3.14 2 0 12 17 68
0 78 64.00 91 5.68 64.00 56 3.50 151.58 33 4.88 2 0 9 18 70
0 78 64.00 82 5.12 64.00 54 3.37 139.28 36 4.89 2 0 11 18 68
0 78 64.00 89 5.56 64.00 60 3.75 245.82 22 5.28 2 0 8 16 73
Первые два - SATA, третий - системный скази, раздают все. Системный конечно
переформатированию не подвергался.
Вопрос - почему у всех винтов отформатированных с блоком 64kb, KB/t
стабильно - 64.00 и плавают только tps? А у системного KB/t - заметно
поприличнее!
Но это когда работает только nginx, запускаю mc и копирую файл с диска на
диск, несмотря на то что gstat говорит 90% занятости, файл копируется легко
в 20+мег в секунду, а iostat показывает следующее:
0 358 512.00 108 53.95 0.00 0 0.00 512.00 108 53.95 4 0 11 2 83
0 331 512.00 105 52.45 0.00 0 0.00 512.00 105 52.45 2 0 11 1
86
0 491 512.00 108 53.95 0.00 0 0.00 512.00 108 53.95 4 0 12 1
83
0 361 512.00 109 54.45 0.00 0 0.00 512.00 109 54.45 3 0 12 2
83
Заветные 512, как завещал sfreadahead! И колечество операций tps даже
практически не выросло! Ничего не понимаю! Можно как-то, без
переформатирования всех дисков обратно, заставить nginx читать поумнее? или
дело вообще в чем-то другом?
--
Best regards,
Anton Kuznetsov.
В спеке FastCGI указано, что соединения между веб-сервером и
fastcgi-сервером могут быть постоянными, при этом nginx в
FCGI_BEGIN_REQUEST не указывает флаг FCGI_KEEP_CONN, в результате чего
fastcgi-сервер закрывает соединение после ответа.
Существует ли возможность в nginx делать соединения с fastcgi-сервером
постоянными или это впринципе не реализовано?
Я так понимаю, что при тысячах запросов от клиентов nginx делает
тысячи попыток соединиться с fastcgi-сервером (1 запрос = 1 соединение
к fastcgi), которому приходится разгребать все эти соединения, а чаще
всего просто получаем ECONNREFUSED, не было бы лучше
мультиплексировать все запросы по нескольким постоянным соединениям?
Подскажите, как это сделать, если это сделать нельзя, то планируется
ли реализация такого поведения в будущем?
Заранее спс.
Hello, all
Всем доброе время суток, начал свой сайт переводить с flv на mp4, пока
тестирую, нашел только 1 модуль под h264, вот это :
http://h264.code-shop.com/trac/wiki/Mod-H264-Streaming-Nginx-Version2
Как в рассылке пробегало, код ужасен :), но ничего другого не нашел,
вот и возник вопрос - по идее вещь интересная (качество видео, размер
файла - все лучше чем у флв), не планируется создание и включение
"нормально" написанного модуля в nginx ? или может кто уже правил этот
модуль ? может кто другой посоветует ?
зы. а еще этот модуль походу течет ужасно, за 4 дня у меня в своп ушло
1.3 гига :(, до этого модуля nginx там вроде не сильно бывал.
--
Решил тут заюзать post_action, чтобы после отдачи страницы документа
юзеру дергать наш сервер аналитики (раньше дергал с бекенда, но щас
приделали squid перед ним - не выходит, так как 90% запросов отдаются
из кеша).
Сделал вот так:
location = @analytics_docview {
internal;
proxy_set_header X-Analytics-page_type 'document';
proxy_set_header X-Analytics-docview_uri $docview_uri;
proxy_set_header X-Analytics-referer $http_referer;
proxy_set_header X-Analytics-user_agent $http_user_agent;
proxy_set_header X-Analytics-user_ip $remote_addr;
proxy_connect_timeout 5;
proxy_read_timeout 5;
proxy_send_timeout 5;
access_log logs/analytics-api.log main;
error_log logs/analytics-api.error.log debug;
proxy_pass http://XXXXXXX:4000/collector/register_hit;
}
# Distribute queries among different mongrel packs
# DOCVIEW page - with caching
location /doc/ {
access_log logs/scribd.analytics.log analytics;
add_header X-Served-By backend;
set $docview_uri $uri;
post_action @analytics_docview;
..........................................
... много всего, в основном
... proxy_pass'ы всякие
..........................................
}
Результат оказался странным:
1) В еррор логе:
2008/12/11 02:20:38 [error] 7402#0: *36 could not find named location
"@analytics_docview" while sending to client, client: 66.249.90.136, s
erver: *.scribd.com, request: "GET
/doc/10536/PAN-F49A?query2=WWW.tininfo%40nsdl.co.in HTTP/1.0",
upstream: "http://10.10.170.18:8080/doc/10
536/PAN-F49A?query2=WWW.tininfo%40nsdl.co.in", host: "www.scribd.com"
2) проверял на трафике в 50+ QPS и за 10-15 секунд получил десяток
core-файлов :-/
Core was generated by `nginx: worker process '.
Program terminated with signal 11, Segmentation fault.
#0 0x0000000000409e3c in ngx_vsnprintf (buf=0x7fff5291f12c "?*",
max=<value optimized out>, fmt=<value optimized out>,
args=0x7fff5291f030) at src/core/ngx_string.c:426
426 *--p = (u_char) (ui32 % 10 + '0');
(gdb) bt
#0 0x0000000000409e3c in ngx_vsnprintf (buf=0x7fff5291f12c "?*",
max=<value optimized out>, fmt=<value optimized out>,
args=0x7fff5291f030) at src/core/ngx_string.c:426
#1 0x000000000040a219 in ngx_snprintf (buf=0x7fff5291f12c "?*",
max=140734578683891, fmt=0x2ff <Address 0x2ff out of bounds>)
at src/core/ngx_string.c:100
#2 0x0000000000406353 in ngx_log_error_core (level=4, log=0x7d2f00,
err=0, fmt=0x45e090 "could not find named location \"%V\"")
at src/core/ngx_log.c:98
#3 0x000000000042901b in ngx_http_named_location (r=0x700640,
name=0x671d40) at src/http/ngx_http_core_module.c:1934
#4 0x000000000042b560 in ngx_http_post_action (r=0x700640) at
src/http/ngx_http_request.c:2560
#5 0x000000000042cd35 in ngx_http_finalize_request (r=0x700640,
rc=500) at src/http/ngx_http_request.c:1706
#6 0x0000000000429028 in ngx_http_named_location (r=0x700640,
name=0x671d40) at src/http/ngx_http_core_module.c:1937
#7 0x000000000042b560 in ngx_http_post_action (r=0x700640) at
src/http/ngx_http_request.c:2560
#8 0x000000000042cd35 in ngx_http_finalize_request (r=0x700640,
rc=500) at src/http/ngx_http_request.c:1706
#9 0x0000000000429028 in ngx_http_named_location (r=0x700640,
name=0x671d40) at src/http/ngx_http_core_module.c:1937
#10 0x000000000042b560 in ngx_http_post_action (r=0x700640) at
src/http/ngx_http_request.c:2560
#11 0x000000000042cd35 in ngx_http_finalize_request (r=0x700640,
rc=500) at src/http/ngx_http_request.c:1706
#12 0x0000000000429028 in ngx_http_named_location (r=0x700640,
name=0x671d40) at src/http/ngx_http_core_module.c:1937
#13 0x000000000042b560 in ngx_http_post_action (r=0x700640) at
src/http/ngx_http_request.c:2560
#14 0x000000000042cd35 in ngx_http_finalize_request (r=0x700640,
rc=500) at src/http/ngx_http_request.c:1706
#15 0x0000000000429028 in ngx_http_named_location (r=0x700640,
name=0x671d40) at src/http/ngx_http_core_module.c:1937
#16 0x000000000042b560 in ngx_http_post_action (r=0x700640) at
src/http/ngx_http_request.c:2560
#17 0x000000000042cd35 in ngx_http_finalize_request (r=0x700640,
rc=500) at src/http/ngx_http_request.c:1706
#18 0x0000000000429028 in ngx_http_named_location (r=0x700640,
name=0x671d40) at src/http/ngx_http_core_module.c:1937
#19 0x000000000042b560 in ngx_http_post_action (r=0x700640) at
src/http/ngx_http_request.c:2560
.............
............тут очень много одинаковых блоков вызовов (злобная такая рекурсия)
............
#39500 0x000000000042cd35 in ngx_http_finalize_request (r=0x700640,
rc=500) at src/http/ngx_http_request.c:1706
#39501 0x0000000000429028 in ngx_http_named_location (r=0x700640,
name=0x671d40) at src/http/ngx_http_core_module.c:1937
#39502 0x000000000042b560 in ngx_http_post_action (r=0x700640) at
src/http/ngx_http_request.c:2560
#39503 0x000000000042cd35 in ngx_http_finalize_request (r=0x700640,
rc=500) at src/http/ngx_http_request.c:1706
---Type <return> to continue, or q <return> to quit---
Дальше мне надоело жать ентер :-)
Внимание, вопрос: что делать? :-(
--
Alexey Kovyrin
http://kovyrin.info/
Здравствуйте.
Пока пофиксить рост Writing с нашими патчами не удалось, но случайно
удалось воспроизвести рост на непатченном nginx-е, раздающем картинки
с диска. См. атач.
Собран nginx из портов с обычными опциями:
/usr/local/sbin/nginx -V
nginx version: nginx/0.7.33
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt=-I /usr/local/include --with-ld-opt=-L /usr/local/lib --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx-error.log --user=www --group=www --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-log-path=/var/log/nginx-access.log --with-http_stub_status_module
Ранее стоял 0.7.22 и подобного роста не наблюдалось. Обновил сегодня
ночью и Writing начал почему-то расти.
ММ> Хотя похоже это не в ngx_http_upstream_keepalive, а в наших патчах.
ММ> Собрал без ngx_http_upstream_keepalive и всёравно растёт Writing.
ММ>> Прошу прощения за неточность. С ngx_http_upstream_keepalive
ММ>> ненормально растёт Writing, а не Waiting. И 200-300 - это именно для
ММ>> Writing в это время суток специфично. А Waiting имеет нормальное
ММ>> значение.
>>>> Поставил http://mdounin.ru/hg/ngx_http_upstream_keepalive/ . Нагрузка
>>>> на мемкашеды заметно упала. Но возник вопрос по мониторингу:
>>>> закэшированные соединения отражаются в stub-status-е или нет?
MD>>> Должны быть видны как waiting.
--
С уважением,
Михаил Монашёв, SoftSearch.ru
mailto:postmaster@softsearch.ru
ICQ# 166233339
http://michael.mindmix.ru/
Без бэкапа по жизни.
Изменения в nginx 0.7.34 10.02.2009
*) Добавление: параметр off в директиве if_modified_since.
*) Добавление: теперь после команды XCLIENT nginx посылает команду
HELO/EHLO.
Спасибо Максиму Дунину.
*) Добавление: поддержка Microsoft-специфичного режима
"AUTH LOGIN with User Name" в почтовом прокси-сервере.
Спасибо Максиму Дунину.
*) Исправление: в директиве rewrite, возвращающей редирект, старые
аргументы присоединялись к новым через символ "?" вместо "&";
ошибка появилась в 0.1.18.
Спасибо Максиму Дунину.
*) Исправление: nginx не собирался на AIX.
--
Игорь Сысоев
http://sysoev.ru
Hello,
nginx-0.5.35.
Пользую FCGI::ProcManager. Обнаружил, что CGI.pm работает неправильно, привязал CGI::Fast.
Переменные из GET берёт хорошо, а из POST --- нет.
Порылся в исходниках FCGI, и понял, что POST обрабатывается в CGI.pm.
Собственно проблема с nginx в том, что я ему пишу в конфиге
===
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
===
а переменные в FCGI::ProcManager попадают в %ENV:
===
HTTP_CONTENT_TYPE
HTTP_CONTENT_LENGTH
===
остальные прописанные в конфиге --- идут как есть. И действительно, вот я вставляю в мой FCGI::Spawn:
===
map { $ENV{ $_ } = $ENV{ "HTTP_$_" } } qw/CONTENT_LENGTH CONTENT_TYPE/
if $ENV{ 'REQUEST_METHOD' } eq 'POST';
===
перед "new CGI::Fast" --- и переменные им берутся как надо.
Вопрос в чём: я всё оставляю как сейчас, или это бага nginx? а то мы спецификаций да сишных исходников не читатели, только почитатели-причитатели :)
73! Peter
--
http://vereshagin.org
server {
location /foo/bar {
proxy_pass http://backend-cluster;
}
location / {
proxy_pass http://somehost;
}
}
Если запрос приходит на /foo/bar но backend-cluster не отвечает, то
запрос перекидывается на somehost - который не знает как обработать
запрос типа /foo/bar.
**proxy_next_upstream ничего не меняет.
Также без успеха пробовал добавить
location /foo {
return 403;
}
Устал уже повторять фундамент. :)
Раздаю большие файлы, на больших скоростях. FreeBSD & nginx
имею такую постоянную болезнь по логам - обрывы связи с кусками примерно по
64к:
81.27.246.58 - - [02/Apr/2009:15:25:52 +0400] GET
/film/sluzhebnyj.roman.1.avi HTTP/1.0 ZZ 200 88334336
92.124.3.154 - - [02/Apr/2009:15:25:54 +0400] GET
/film/moskva.slezam.ne.verit.avi HTTP/1.0 ZZ 206 63489
92.124.3.154 - - [02/Apr/2009:15:25:56 +0400] GET
/film/moskva.slezam.ne.verit.avi HTTP/1.0 ZZ 206 63779
77.51.24.79 - - [02/Apr/2009:15:25:58 +0400] GET
/multiki/zolotoj.kluchik.avi HTTP/1.0 ZZ 206 63706
77.52.122.248 - - [02/Apr/2009:15:26:02 +0400] GET
/multiki/bolek.i.lolek.zlote.miasto.inkow.avi HTTP/1.1 XX 206 64999
194.154.66.131 - - [02/Apr/2009:15:26:04 +0400] GET
/filmiki/prikljuchenija.elektronika.1.avi HTTP/1.1 ZZ 206 2321244
87.247.1.93 - - [02/Apr/2009:15:26:14 +0400] GET
/filmiki/prikljuchenija.elektronika.2.avi HTTP/1.1 ZZ 206 62239
217.117.76.55 - - [02/Apr/2009:15:26:14 +0400] GET
/film/sledstvie.vedut.znatoki.21.2.avi HTTP/1.1 XX 206 60590
Хочу чтобы все строчки в логе были как первая - человек взял и скачал фильм
- ответ 200, размер - почти гиг и все счастливы. Не знаю как оценить
количество тех кому удается скачать за раз - их записи в логе тонут в
обрывках по 64к. Я уже установил req_limit как временное решение, до этого
лог был похож на ужас летящий на крыльях ночи - десятки адресов на хорошей
скорости выкачивают по 64к в секунду или даже по несколько, т.е. канал им
позволяет качать хорошо. Бывают куски и побольше, 120к, вот в примере у кого
2м, но чаще всего 64к. Это происходит постоянно. Даже когда нагрузка на
винчестеры, скорость и общее количество коннектов - в разы меньше от
пиковой.
В чем проблема? Может буфера в системе/nginx подкрутить надо?
По-моему когда-то давно такое было и на апаче. :(
Добавлю еще один факт. Недавно удалось побыть таким неудачником у себя дома.
Взял из лога урл имени 64к - даю wget-у - бац, обрыв! еще раз, еще...
03:42:52 (16.27 KB/s) - Read error at byte 33329/1465085952 (No such file or
directory). Retrying.
В жизни такого не было. Беру другой урл - качает! Снова пробую первый -
обрывы! 100% диагностика. На следующий день попробовал - все хорошо.
P.S. Игорь - могу дать рута. :)
--
Best regards,
Anton Kuznetsov.
Здравствуйте, подскажите пожалуйста как написать хандлер на обработку ПОСТ запроса, наподобе как на локейшн вешается свой хендлер, хочу повесить хендлер на ПОСТ запрос и где искать тело ПОСТ запроса в структуре ngx_http_request_s.
Заранее спасибо!