Gena Makhomed | 1 Jun 01:46

Re: nginx memcache proxy_store fastcgi_store

On Sunday, June 1, 2008 at 1:45:14, Alexey V. Karagodov wrote:

>> если на сервере будет такая уязвимая конфигурация,
>> что весь контент хранится в memcached, тогда будет
>> очень легко устроить Denial-of-service, например,
>> сделав на 8 гиг запросов к несуществующим или
>> редкоиспользуемым страницам.

AVK> мне ж не всё нужно. только "избранное".

если не "всё", а только "избранное" - то помещать
информацию в memcached должен не nginx, а backend

такая схема работы уже реализована и поддерживается
в nginx:
http://sysoev.ru/nginx/docs/http/ngx_http_memcached_module.html

>> существующий сегодня в nginx файловый кеш -
>> быстрее предлагаемого "решения" с memcached

AVK> можно подробней. боюсь неправильно понять ...

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

по крайней мере, так на Linux при использовании XFS, но
скорее всего,
(Continue reading)

Re: nginx memcache proxy_store fastcgi_store


On 01.06.2008, at 3:46, Gena Makhomed wrote:

> On Sunday, June 1, 2008 at 1:45:14, Alexey V. Karagodov wrote:
>
>>> если на сервере будет такая уязвимая  
>>> конфигурация,
>>> что весь контент хранится в memcached,  
>>> тогда будет
>>> очень легко устроить Denial-of-service,  
>>> например,
>>> сделав на 8 гиг запросов к  
>>> несуществующим или
>>> редкоиспользуемым страницам.
>
> AVK> мне ж не всё нужно. только  
> "избранное".
>
> если не "всё", а только "избранное" - то  
> помещать
> информацию в memcached должен не nginx, а backend
>
> такая схема работы уже реализована и  
> поддерживается в nginx:
> http://sysoev.ru/nginx/docs/http/ngx_http_memcached_module.html

>
>>> существующий сегодня в nginx файловый  
>>> кеш -
>>> быстрее предлагаемого "решения" с  
>>> memcached
(Continue reading)

поправки к "100-200 тысяч соединений" для FreeBSD 7 ( i386 и amd64 )

Keywords: freebsd tcp optimization tune speed socket mbuf sendfile sysctl From: Сысоев Игорь Владимирович <http://www.sysoev.ru> Date: Mon, 1 Oct 2007 14:31:37 +0000 (UTC) Subject: FreeBSD для обслуживания 100-200 тысяч соединений [[http://rutube.ru/tracks/125719.html?v=23351111db90ae8beace6a841dd2a8f4%EE%C1%D3%D4%D2%CF%CA%CB%C1 Видеоролик доклада]]
######## мои дополнения отмечены ######## в начале строки ######## в самом низу даны "итоговые" файлы конфигурации /boot/loader.conf /etc/sysctl.conf и ядер для i386 и amd64 Стенограмма выступления Игоря Сысоева с конференции РИТ-2007. mbuf clusters FreeBSD хранит сетевые данные в mbuf clusters, размер каждого 2Кб, но из них используется только около 1500 байт (по размеру Ethernet пакета). mbufs Для каждого mbuf кластера нужен "mbuf", который имеет размер 256 байт и нужен для организации связи цепочек из mbuf кластеров. В mbuf можно поместить полезную информацию в районе 100 байт, но это не всегда используется. Если в машине 1Гб и больше памяти, то по умолчанию будет создано 25 тыс. mbuf кластеров, что не всегда достаточно. При ситуации исчерпания числа свободных mbuf кластеров FreeBSD попадает в состояние zonelimit и перестает отвечать на запросы по сети, в top это выглядит как "zoneli". Единственная возможность как-то повлиять на ситуацию - это зайти с локальной консоли и перезагрузить систему, уничтожить процесс находящийся в состоянии "zoneli" невозможно. Для Linux 2.6.x данная проблема тоже характерна, причем работать переставала даже консоль. PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 13654 nobody 1 4 0 59912K 59484K zoneli 209:26 0.00% nginx Для выхода из этой ситуации существует патч возвращающий приложению ошибку ENOBUFS, сигнализирующий о попадании в состояние "zoneli", после чего программа может закрыть лишние соединения. К сожалению патч пока не принят в состав FreeBSD. Состояние задействованных mbuf кластеров можно посмотреть командой: >netstat -m 4/1421/1425 mbufs in use (current/cache/total) 0/614/614/25600 mbuf clusters in use (current/cache/total/max) Увеличение числа mbuf кластеров во FreeBSD 6.2 можно произвести в любой момент через параметр kern.ipc.nmbclusters: sysctl kern.ipc.nmbclusters=65536 Для более ранних версий FreeBSD число mbuf кластеров можно было установить только на этапе загрузки: /boot/loader.conf: kern.ipc.nmbclusters=65536 25000 mbuf clusters = 55M 32768 mbuf clusters = 74M 65536 mbuf clusters = 144M 25000 mbuf кластеров занимают примерно 50Мб памяти, 32000 - 74 Мб, 65000 - 144Мб (рост по степени 2). 65000 - пограничное значение, превышать которое не рекомендуется, без предварительного расширения адресного пространства доступного ядру. ++ Увеличение памяти, доступной ядру Увеличение адресного пространства ядра, которое на i386 платформе - 1Гб. Для увеличения до 2Гб, в файле конфигурации ядра необходимо указать: options KVA_PAGES=512
######## для amd64 оказалось недостаточно указать vm.kmem_size_max=1G в /boot/loader.conf, ######## (параметр был просто игнорирован) по-этому это надо сделать в файле конфигурации ядра: ######## options VM_KMEM_SIZE=1073741824
######## options VM_KMEM_SIZE_MAX=1073741824
На платформе amd64 KVA всегда 2G, увеличить к сожалению в настоящее время нельзя. Кроме увеличения виртуального адресного пространства можно увеличить лимит физической памяти, которую может использовать ядро (по умолчанию 320Мб). Увеличим до 1Гб: /boot/loader.conf: vm.kmem_size=1G ######## для обеих платформ добавить vm.kmem_size_max=1G Затем выделим из него 575Мб под mbuf кластера: sysctl -w kern.ipc.nmbclusters=262144 ++ Установление соединения. syncache и syncookies Примерно 1000 байт расходуется на одно соединение. Примерно 100 байт для одной записи на незаконченное соединение в syncache. Всего можно держать в памяти информацию об около 15000 соединениях. Параметры syncache можно посмотреть через "sysctl net.inet.tcp.syncache" (доступен в режиме только для чтения): # sysctl net.inet.tcp.syncache net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncache.cachelimit: 15359 net.inet.tcp.syncache.count: 29 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.rexmtlimit: 3 Изменить параметры syncache можно только на этапе загрузки ядра: /boot/loader.conf: net.inet.tcp.syncache.hashsize=1024 net.inet.tcp.syncache.bucketlimit=100 Когда новое соединение не помещается в переполненный syncache, FreeBSD переходит в режим "syncookies" (TCP SYN cookies). Включается возможность такого перехода через: sysctl net.inet.tcp.syncookies=1 Заполненность syncache и статистику по syncookies можно посмотреть через команду: netstat -s -p tcp ... 2079088720 syncache entries added ... > 0 dropped 2058506523 completed > 0 bucket overflow > 0 cache overflow ... 0 cookies sent 0 cookies received После того как соединение принято оно попадает в "listen socket queue". Статистику можно посмотреть командой netstat -Lan Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 43/0/4096 *.80 tcp4 0/0/128 *.22 4096 - размер очереди (максимум 65тыс.) 43 - заполненность очереди в данный момент (приложение не вытащило из очереди). Увеличение размера очереди производится через: sysctl kern.ipc.somaxconn=4096 После того как соединение принято для него FreeBSD создает структуры связанные с сокетами (sockets). Увеличить максимальное число открытых сокетов во FreeBSD 6.2, во время работы, можно через: sysctl kern.ipc.maxsockets=204800 В более ранних версиях: /boot/loader.conf: kern.ipc.maxsockets=204800 Посмотреть состояние можно командой: >vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES ... socket: 356, 204809, 48041, 114869, 4292783585, 0 ... inpcb: 180, 204820, 63956, 121460, 4283258030, 0 tcpcb: 464, 204800, 48015, 114897, 4283258030, 0 ++ tcb hash Если машина обрабатывает несколько десятков тысяч соединений то tcb hash позволяет быстро определять принадлежность пришедшего пакета к определенному соединению. По умолчанию размер tcb hash - 512 элементов. Текущий размер можно посмотреть через sysctl (только для чтения): sysctl net.inet.tcp.tcbhashsize Изменить можно на этапе загрузки: /boot/loader.conf: net.inet.tcp.tcbhashsize=4096 ++ Файлы Приложения работают не с сокетами, а с файлами. По этому для каждого сокета нужна структура, которая описывает файл. Увеличить можно через: sysctl kern.maxfiles=204800 sysctl kern.maxfilesperproc=200000 kern.maxfiles - всего файлов в системе kern.maxfilesperproc - максимальное число файлов на один процесс. Параметры можно менять на работающей системе, но они не отразятся на уже запущенных процессах. Поэтому в nginx были добавлены директивы позволяющие менять число открытых файлов для уже запущенных процессов (после инициирования операции переконфигурации) nginx.conf: worker_rlimit_nofile 200000; events { worker_connections 200000; } ++ receive buffers Буферы для приема данных. По умолчанию 64Kб, если нет загрузки больших объемов данных, то можно уменьшить до 8Кб (меньше вероятность переполнения при DoS атаке). sysctl net.inet.tcp.recvspace=8192 Для nginx: nginx.conf: listen 80 default rcvbuf=8k; ++ send buffers Буферы для отправки данных. По умолчанию 32K. Если скачиваются данные небольшого объема или недостаток mbuf кластеров, можно уменьшить: sysctl net.inet.tcp.sendspace=16384 Для nginx: nginx.conf: listen 80 default sndbuf=16k; В ситуации когда сервер записал в сокет данные, но клиент не хочет их забирать, после таймаута по закрытию соединения в ядре данные будут держаться еще несколько минут. В nginx если директива для принудительного сброса всех данных после закрытия по таймауту. nginx.conf: reset_timedout_connections on; ++ sendfile Еще один механизм для экономии mbuf кластеров - это sendfile, он использует память буферов ядра с данными файлов одновременно для передачи этих данных в сетевую карту, без промежуточного заполнения лишних буферов. В nginx включается: nginx.conf: sendfile on; На i386 по умолчанию для систем с 1 или более Гб памяти будет выделено 6656 sendfile буферов. Этого вполне достаточно. На платформе amd64 более оптимальный вариант реализации и sfbufs буферы не нужны. Статистика: i386>netstat -m ... 190/510/6656 sfbufs in use (current/peak/max) amd64>netstat -m ... 0/0/0 sfbufs in use (current/peak/max) При переполнении sendfile буфера процесс замирает в состоянии "sfbufa", но ситуация достаточно быстро приходит в норму после увеличения размера буфера. PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 13654 nobody 1 4 0 59912K 59484K sfbufa 209:26 5.00% nginx Увеличение размера через: /boot/loader.conf: kern.ipc.nsfbufs=10240 ++ TIME_WAIT После того как соединение закрывается сокет переходит в состояние TIME_WAIT В этом состоянии он может находится по умолчанию в течение 60 секунд. Время можно изменить через sysctl (в миллисекундах деленных на 2, 2 x 30000 MSL = 60 секунд): sysctl net.inet.tcp.msl=30000 Во FreeBSD 6.2 TIME_WAIT сокеты обрабатываются отдельно (нужна лишь часть информации 48 байт из 1 Кб. Ограничение вне лимита kern.ipc.maxsockets), число их регулируется параметром: sysctl net.inet.tcp.maxtcptw=40960 Статистика: >vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES ... tcptw: 48, 41028, 15941, 25087, 1045159949, 438573 ++ TCP/IP ports По умолчанию исходящие соединения инициируются с диапазона портов 49152-65535 (16 тыс.). Их неплохо увеличить (1024-65535): sysctl net.inet.ip.portrange.first=1024 sysctl net.inet.ip.portrange.last=65535 Для использования портов по порядку, вместо случайной выборки (для исключения ошибки повторного коннекта с одного порта до отработки TIME_WAIT): sysctl net.inet.ip.portrange.randomized=0 Во FreeBSD 6.2 появилась возможность не создания состояния TIME_WAIT для соединений в рамках localhost: sysctl net.inet.tcp.nolocaltimewait=1


######## /usr/src/sys/amd64/conf/CUSTOM include GENERIC device pf device pflog device pfsync device carp options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ options ALTQ_NOPCC #options QUOTA options IPSEC #options IPSEC_FILTERGIF device crypto device cryptodev options DEVICE_POLLING #options HZ=1000 #options SCHED_ULE #options KVA_PAGES=512 options VM_KMEM_SIZE=1073741824 options VM_KMEM_SIZE_MAX=1073741824 options PANIC_REBOOT_WAIT_TIME=60 ident CUSTOM

######## /usr/src/sys/i386/conf/CUSTOM

include GENERIC

device pf
device pflog
device pfsync
device carp

options ALTQ
options ALTQ_CBQ
options ALTQ_RED
options ALTQ_RIO
options ALTQ_HFSC
options ALTQ_CDNR
options ALTQ_PRIQ
options ALTQ_NOPCC

#options QUOTA

options IPSEC
#options IPSEC_FILTERGIF
device crypto
device cryptodev

options DEVICE_POLLING
#options HZ=1000

#options SCHED_ULE

options KVA_PAGES=512

options VM_KMEM_SIZE=1073741824
options VM_KMEM_SIZE_MAX=1073741824

options PANIC_REBOOT_WAIT_TIME=60

ident CUSTOM


######## /boot/loader.conf verbose_loading="YES" loader_logo="beastie" #ng_ether_load="YES" #linux_load="YES" accf_data_load="YES" accf_http_load="YES" net.inet.tcp.syncache.hashsize=1024 net.inet.tcp.syncache.bucketlimit=100 net.inet.tcp.tcbhashsize=4096 kern.ipc.nsfbufs=10240 vm.kmem_size=1G vm.kmem_size_max=1G

######## /etc/sysctl.conf
net.inet.tcp.blackhole=1
net.inet.udp.blackhole=1
kern.ipc.nmbclusters=262144
kern.ipc.somaxconn=4096
kern.ipc.maxsockets=204800
kern.maxfiles=204800
kern.maxfilesperproc=200000
net.inet.ip.portrange.first=1024
net.inet.ip.portrange.last=65535
net.inet.ip.portrange.randomized=0
net.inet.tcp.recvspace=8192
net.inet.tcp.sendspace=16384
net.inet.tcp.maxtcptw=40960
net.inet.tcp.msl=30000
net.inet.tcp.syncookies=1
net.inet.tcp.nolocaltimewait=1
net.inet.tcp.fast_finwait2_recycle=1 


######## после всех мытарств, работа системы весьма порадовала.
######## комменты только приветствуются.
######## огромное пожелание к Игорю включить сей опус с поправками и комментариями (кои лично меня ОЧЕНЬ интересуют) в документацию на своём сайте.

######## данные конфиги являются результатом печального опыта. если не указывать vm.kmem_size_max, ядру нехватит памяти, для всей этой красоты.
######## успехов

Re: Проблемы с загрузкой файлов

пардон, а прогресс бар у вас с nginx-ом работает с этим модулем?

01.06.08, Rauan Maemirov <rauan1987 <at> gmail.com> написал(а):
Да-да. конечно. :) проблема оказалась в javascript, а не на сервере. Всем спасибо.

2008/6/1 David Mzareulyan <david <at> hiero.ru>:

ОБА размера проставлены нормально?


Пусто. Забыл сказать, что в php.ini размеры проставлены нормально.

2008/5/31 Alexey Kovyrin <alexey <at> kovyrin.net>:

что в логах?

2008/5/31 Rauan Maemirov <rauan1987 <at> gmail.com>:

Всем привет. Использую SWFUpload для заливки. Маленькие файлы
загружаются нормально. А вот размером с 30-40мб проблемы.

Хотя стоит client_max_body_size 50m;

Возможно есть еще какой-то таймаут?

--
Alexey Kovyrin
http://kovyrin.info/


--
С уважением
Давид Мзареулян
david <at> hiero.ru








--
С уважением,
Паньков Артем Владимирович.
ICQ: : 842264
Мобильный: +7 926 565 26 13
Rauan Maemirov | 1 Jun 10:14
Picon
Gravatar

Re: Проблемы с загрузкой файлов

Неа. В обсуждениях посоветовали не использовать его (Если вы о codemonger-овском NginxUploadProgress), так как он много жрет. А используется swfupload, т.е. загрузкой и отображением прогреса занимается flash. Интересно, когда уже можно будет пользоваться тем модулем.

2008/6/1 Артем Паньков <artem <at> pankov.biz>:
пардон, а прогресс бар у вас с nginx-ом работает с этим модулем?

01.06.08, Rauan Maemirov <rauan1987 <at> gmail.com> написал(а):
Да-да. конечно. :) проблема оказалась в javascript, а не на сервере. Всем спасибо.

2008/6/1 David Mzareulyan <david <at> hiero.ru>:

ОБА размера проставлены нормально?


Пусто. Забыл сказать, что в php.ini размеры проставлены нормально.

2008/5/31 Alexey Kovyrin <alexey <at> kovyrin.net>:

что в логах?

2008/5/31 Rauan Maemirov <rauan1987 <at> gmail.com>:

Всем привет. Использую SWFUpload для заливки. Маленькие файлы
загружаются нормально. А вот размером с 30-40мб проблемы.

Хотя стоит client_max_body_size 50m;

Возможно есть еще какой-то таймаут?

--
Alexey Kovyrin
http://kovyrin.info/


--
С уважением
Давид Мзареулян
david <at> hiero.ru








--
С уважением,
Паньков Артем Владимирович.
ICQ: : 842264
Мобильный: +7 926 565 26 13

Gena Makhomed | 1 Jun 15:05

Re: nginx memcache proxy_store fastcgi_store

On Sunday, June 1, 2008 at 3:26:40, Alexey V. Karagodov wrote:

>> такая схема работы уже реализована и
поддерживается в nginx:
>> http://sysoev.ru/nginx/docs/http/ngx_http_memcached_module.html

AVK> я согласен с общей концепцией, что девелоперам
AVK> надо больше заниматься своим делом ...

не обязательно девелоперам. location @fallback { perl setcache::handler; }
setcache::handler - берет контент с backend`а и сохраняет его в memcached.

--

-- 
Best regards,
 Gena

Re: nginx memcache proxy_store fastcgi_store


On 01.06.2008, at 17:05, Gena Makhomed wrote:

> On Sunday, June 1, 2008 at 3:26:40, Alexey V. Karagodov wrote:
>
>>> такая схема работы уже реализована и  
>>> поддерживается в nginx:
>>> http://sysoev.ru/nginx/docs/http/ngx_http_memcached_module.html

>
> AVK> я согласен с общей концепцией, что  
> девелоперам
> AVK> надо больше заниматься своим  
> делом ...
>
> не обязательно девелоперам. location  
> @fallback { perl setcache::handler; }
> setcache::handler - берет контент с backend`а и  
> сохраняет его в memcached.
если я решу эту проблему сам, то  
возможны неприятные последствия
неактуальные страницы и тд и тп
контентом я не занимаюсь и не могу  
решить что там когда и как
моя "миссия" указать девелоперам, что  
что-то можно сделать ещё и так-то и вот  
так-то
ну и совместно потом реализовать
  "я, за разделение труда"
>
>
> -- 
> Best regards,
> Gena
>
>

Gena Makhomed | 1 Jun 16:26

Re: nginx memcache proxy_store fastcgi_store

On Sunday, June 1, 2008 at 16:44:30, Alexey V. Karagodov wrote:

GM>>>> http://sysoev.ru/nginx/docs/http/ngx_http_memcached_module.html

GM>> location @fallback { perl setcache::handler; }
GM>> setcache::handler - берет контент с backend`а и сохраняет его в memcached.

AVK> если я решу эту проблему сам, то возможны
AVK> неприятные последствия
AVK> неактуальные страницы и тд и тп
AVK> контентом я не занимаюсь и не могу
AVK> решить что там когда и как
AVK> моя "миссия" указать девелоперам,
AVK> что что-то можно сделать ещё и так-то
AVK> и вот так-то ну и совместно потом реализовать
AVK> "я, за разделение труда"

то что я выше написал - это реализация
proxy_store и fastcgi_store в memcache
средствами nginx (скрипт на mod_perl).

===================================================================

On Saturday, May 31, 2008 at 2:59:17, Alexey V. Karagodov wrote:

AVK> всем привет

AVK> планируется-ли реализация proxy_store и  
AVK> fastcgi_store в memcache?

===================================================================

--

-- 
Best regards,
 Gena

sleepy | 1 Jun 16:34
Picon

Re: Nginx+linux

В сообщении от Sunday 01 June 2008 00:59:18 pavel <at> pronskiy.ru написал(а):
> У меня конфигурация приблизительно такая же, только
процессор E6600 и
> памяти 2gb
> В среднем соединений не так много, примерно 150-200
постоянных, страницы
> отдаются моментально без кэширования запросов.
> Попробуйте такие настройки:

Спасибо, поковырял, пока 
[root <at> stuff ~]# netstat -n |grep EST|wc -l
316
[root <at> stuff ~]#

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

на моей системе значения :

net.ipv4.tcp_max_syn_backlog = 1024
net.core.somaxconn = 1024
net.core.netdev_max_backlog = 1000

число php процессов поднял до 60ти nginx опустил до 2
включил гзип и прочее, 
как вы присылали конфиг. 

Всем спасибо, посмотрим что будет дальше.

Re: nginx обслуживает более миллиона сайтов !

Тем временем, http://survey.netcraft.com/Reports/200806/ - сайтов
больше двух миллионов!

4 апреля 2008 г. 0:55 пользователь Andrei Nigmatulin
<andrei.nigmatulin <at> gmail.com> написал:
> Согласно апрельской статистике netcraft за апрель 2008г
количество сайтов в
> мире на nginx перевалило за миллион !
>
> http://survey.netcraft.com/Reports/200804/
>
> Огромные поздравления Игорю в связи с этим
выдающимся, беспрецедентным для
> Рунета достижением !!!
>
>
>
> --
> Andrei Nigmatulin
> GPG PUB KEY 6449830D
>
> Now I lay me down to sleep(3)
> Pray the OS my core to keep
> If I die before I wake
> Pray the Disk my core to take
>

--

-- 
С уважением, Борис Долгов.
icq 77556665
e-mail boris <at> dolgov.name

Gmane