Hi, all!
Есть проблемы с использованием weight в upstream в целях распределения
нагрузки.
Если вес выставлен одинаковый, то нагрузка распределяется равномерно.
Пример:
upstream test_backend {
server localhost:59040 weight=10000;
server other_server:59040 weight=10000;
}
Если же выставить разный вес, то нагрузка распределяется неравномерно по
времени, каждые десять минут меняется сервер и все. Сужу об этом по графикам
загрузки серверов. 10 минут все запросы идут на один сервер, затем 10 мин. на
другой.
Пример:
upstream test_backend {
server localhost:59040 weight=10000;
server other_server:59040 weight=5000;
}
location / {
expires epoch;
fastcgi_pass test_backend;
fastcgi_upstream_max_fails 0;
fastcgi_next_upstream error timeout invalid_header http_500;
include fastcgi_param.conf;
}
Но обнаружил, что если цель треть нагрузки отправлять на другой сервер, то
такое помогает:
upstream test_backend {
server localhost:59040 weight=10000;
server localhost:59040 weight=10000;
server other_server:59040 weight=10000;
}
# nginx -v
nginx version: nginx/0.3.60
# uname -a
Linux tapo.net 2.6.8-2-386 #1 Tue Aug 16 12:46:35 UTC 2005 i686 GNU/Linux
Если имеется такая конструкция в конфиге
location / {
root
/web1/users/mds_rudn/www/download.mds.rudn.info/htdocs/;
proxy_pass http://127.0.0.1:80;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-NGX-Request NGX;
proxy_set_header Host $http_host;
index index.html index.htm;
}
И бекенд выдает X-Accel-Redirect - редирект идет снова через proxy_pass
хост? Как этого избежать, т.е. что бы nginx выдавал файл сам по uri
взятому из X-Accel-Redirect с корнем сайта root.
Изменения в nginx 0.5.4 15.12.2006
*) Добавление: директиву perl можно использовать внутри блока
limit_except.
*) Исправление: модуль ngx_http_dav_module требовал строку "Date" в
заголовке запроса для метода DELETE.
*) Исправление: при использовании одного параметра в директиве
dav_access nginx мог сообщить об ошибке в конфигурации.
*) Исправление: при использовании переменной $host мог произойти
segmentation fault; ошибка появилась в 0.4.14.
Игорь Сысоев
http://sysoev.ru
Здравствуйте nginx-ru,
Пару часов назад нас досили и через пару минут после начала атаки
nginx показал 500 ошибку. Причиной тому стало очень много открытых
файлов. OC FreeBSD.
kern.maxfiles: 16424
kern.maxfilesperproc: 14781
kern.openfiles: 610
После начала атаки бэкенд (Апач) не мог отвечать, загруженный
запросами и пытаясь при этом сделать внутренний редирект для nginx.
Логи кое-какие сохранились. Могу выслать.
Вопрос: какие файлы мог создавать nginx в большом количестве и как
этого в будущем избежать?
С уважением,
Михаил Монашёв, SoftSearch.ru
Member of Independent Software Developers Forum (ISDEF)
mailto:postmaster@softsearch.ru
ICQ# 166233339
http://softsearch.ru/
Без бэкапа по жизни.
Добрый день,
после того как кол-во виртуальных хостов перевалило за пол тысячи начались
проблемы.
Nginx не реагирует никак на сигнал HUP. Приходится перезапускать через USR2.
# uname -a
Linux nl3 2.6.17-1.2157_FC5smp #1 SMP Tue Jul 11 23:24:16 EDT 2006 i686 i686
i386 GNU/Linux
# grep server_name /nginx/conf/virt.conf|wc -l
547
Linux, Fedora Core 5
Тестировал на версиях nginx: 0.3.38, 0.4.2
В error.log пусто. Кто-то сталкивался?
Поиском пользовался.
--
Kirill Morozov
Возможно ли настроить nginx так, чтобы в случае если нет заголовка
Last-Modified в ответе от бакенда, nginx сам подставлял текущее время в
этот заголовок.
--
Zherdev Anatoly.
Подскажите пожалуста, есть ли возможность отключить буферизацию POST
запросов и сразу передавать их в frontend?
Есть галерея, в которую пользователи заливают картинки, т.е. наша суровая бытность подразумаевает
малую осведомлённость пользователей в работе web-серверов, они начинают запихивать фотографии по 10-15
мегабайт.
Получаеться что nginx сначала кеширует запрос с файл, потом отдаёт его apache
Хотелось бы какой-либо механизм передачи файла по мере получения, или просто возможность редиректа
POST запроса в frontend.
2006/11/15 13:50:44 [warn] 94741#0: *1577 a client request body is buffered to a temporary file /var/tmp/nginx/client_body_temp/00000000000, client: xx.xx.xx.xx, server: localhost, URL: "/cgi-bin/upload.cgi?upload_id=197294103179&js_on=1&ref=http://xxx.ru:3002/albums/tenneco/3152/addfoto&upload_password=", upstream: "http://xx.xx.xx.xx:80", host: "xxx.ru:3002", referrer: "http://xxx.ru:3002/albums/tenneco/3152/addfoto"
Здравствуйте nginx-ru,
Стоит одна из последних версий nginx-а на FreeBSD 5.5-STABLE . При
обычной нагрузке в top-е nginx приблизительно такой:
last pid: 77484; load averages: 0.42, 0.80, 0.84
146 processes: 1 running, 145 sleeping
CPU states: 22.4% user, 0.0% nice, 10.6% system, 3.5% interrupt, 63.5% idle
Mem: 2793M Active, 796M Inact, 270M Wired, 130M Cache, 112M Buf, 20M Free
Swap: 6144M Total, 5536K Used, 6138M Free
PID PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
...
40801 4 0 14640K 13176K kqread 2 65:33 1.76% 1.76% nginx
40805 4 0 14640K 13556K kqread 2 64:52 0.54% 0.54% nginx
40804 4 0 14640K 13560K kqread 0 64:28 0.29% 0.29% nginx
40802 4 0 14968K 13888K kqread 2 64:09 0.24% 0.24% nginx
40803 4 0 15296K 14108K kqread 2 65:00 0.15% 0.15% nginx
...
(на большой размер процесса не смотрите - там гео-база всю память
занимает)
Далее увеличиваем нагрузку на одном из виртуальных хостов nginx-а.
Начинаем _пятистам_ юзерам отдавать 50 файликов размером в несколько
байт, стучаться на получение новых файликов, получать 404 ошибку,
ждать секунду и стучаться за ними снова и так, пока нужный файлик не
появится на диске. Далее цикл повторяется. Файлки лежат на диске и
отдаются nginx-ом.
В результате top почти не меняется. В нёмного поднимается nginx, что
вполне ожидаемо. И всё нормально работает.
Через несколько минут наступает странная картина: те, процессы (mysqld
и httpd), которые раньше были в верху top-а и которые никак не связаны
с nginx-ом начинают кушать всё больше и больше процессора. Load
average поднимается до 10 и начинаются тормоза. При этом дисковая
активность, судя по iostat, не меняется после увеличения нагрузки.
Процессор также имеет 50-60% idle. Памяти вроде достаточно. Такое
ощущение, что не хватает какого-то другого ресурса, разделяемого
процессами и съеденного nginx-ом.
Вопрос - какого?
С уважением,
Михаил Монашёв, SoftSearch.ru
Member of Independent Software Developers Forum (ISDEF)
mailto:postmaster@softsearch.ru
ICQ# 166233339
http://softsearch.ru/
Без бэкапа по жизни.
nginx 0.5.5, падает в кору
причём размер - 1.7 Гб
конфиг - самый простой, проксирование на апач + отдача статики
Core was generated by `nginx: worker process'.
Program terminated with signal 11, Segmentation fault.
#0 0xb7dbcc1f in memcpy () from /lib/tls/libc.so.6
(gdb) bt
#0 0xb7dbcc1f in memcpy () from /lib/tls/libc.so.6
#1 0x0806e20a in ngx_http_header_filter (r=0x8169348) at src/http/
ngx_http_header_filter_module.c:362
#2 0x080827e5 in ngx_http_userid_filter (r=0x8169348) at src/http/
modules/ngx_http_userid_filter_module.c:240
#3 0x0806823d in ngx_http_special_response_handler (r=0x8169348,
error=499) at src/http/ngx_http_special_response.c:514
#4 0x0806a0f6 in ngx_http_finalize_request (r=0x8169348, rc=499) at
src/http/ngx_http_request.c:1529
#5 0x0806b3f7 in ngx_http_read_request_header (r=0x8169348) at src/
http/ngx_http_request.c:982
#6 0x0806b5c1 in ngx_http_process_request_headers (rev=0xb7bea950)
at src/http/ngx_http_request.c:806
#7 0x08060883 in ngx_epoll_process_events (cycle=0x80aaa40,
timer=500, flags=<value optimized out>) at src/event/modules/
ngx_epoll_module.c:518
#8 0x0805793f in ngx_process_events_and_timers (cycle=0x80aaa40) at
src/event/ngx_event.c:245
#9 0x0805dba0 in ngx_worker_process_cycle (cycle=0x80aaa40,
data=0x0) at src/os/unix/ngx_process_cycle.c:728
#10 0x0805c74d in ngx_spawn_process (cycle=0x80aaa40, proc=0x805d848
<ngx_worker_process_cycle>, data=0x0, name=0x80912cb "worker
process", respawn=0)
at src/os/unix/ngx_process.c:187
#11 0x0805ed8e in ngx_master_process_cycle (cycle=0x80aaa40) at src/
os/unix/ngx_process_cycle.c:555
#12 0x0804af45 in main (argc=-1077697340, argv=0x0) at src/core/
nginx.c:347
Aleksej Besciokov
email/JID: proforg(a)maloletka.ru