Re[6]: странности в работе nginx

[Alexey Bestciokov]

ядро последнее из стабильной ветки - 2.6.11.7
ulimit -n 16384 - это уже проходили :)
в error_log всё чисто
с этого собственно и начал разбирацца.

connections  8192;
epoll_events 8192;

сегодня кстати stub_status показало 10К соединений с утра :)


AD> -----Original Message-----
AD> From: Igor Sysoev <is at rambler-co.ru>
AD> To: nginx-ru at sysoev.ru
AD> Date: Mon, 25 Apr 2005 10:30:49 +0400 (MSD)
AD> Subject: Re[4]: странности в работе nginx

>> 
>> On Mon, 25 Apr 2005, Artem Danilenko wrote:
>> 
>> > AB> да, именно
>> > AB> waitin on disk io действительно большое, по моему не запредельное .
>> > AB> траффик ~ 80 мб, диски - scsi U320 10 000 RMP
>> > AB> на дисковую подсистему не похоже - на сервере где узким место является
>> > AB> гарантированно именно дисковая подсистема, картина другая.
>> > AB> опять же получаемая картина нелинейна - количество коннектов растёт
>> > AB> скачкообразно.
>> > AB> изначально воркеров было 2 - это в процессе экспериментов увеличилось
>> > AB> до 5-8, так при таком количестве nginx визуально адекватнее отвечал.
>> >
>> > AB> странно что появляется задержка при ответе на stub_status -
>> > AB> операции не требующщей чтения с дисков. и почему в выводе стрэйса
>> > AB> задержки ... и то что колиство соединений которое показывает nginx
>> > AB> почти в 2 раза больше чем показывает netstat.
>> >
>> > в error.log ничего странного нету? возможно ли ядро по новее
>> > поставить?(там как минимум раз исправления epoll были)
>> > ulimit -n что показывает? потому что очень похоже на случай когда у
>> > меня не хватило числа открытый файлов одним процессом, то есть
>> > stub_status показывался с задержкой и число соединений, которые
>> > показывал, nginx были раза в 2 больше, чем по netstat
>> 
>> Странные симптомы.
>> 
>> А между какими ядрами были исправления в epoll ?

AD> в 2.6.9
AD> <davidel at xmailserver.org>
AD>         [PATCH] Avoid unnecessary copy for EPOLL_CTL_DEL
	
AD>         Ulrich Drepper points out that EPOLL_CTL_DEL doesn't need to copy any of
AD>         the hash events.
	
AD>         Also, we should specify in the man pages that a NULL is allowed in
AD>         EPOLL_CTL_DEL.  Currently it does not say that. 
	
AD>         Also, starting from when epoll uses rbtrees instead of hashes, the
AD>         'size' hint passed to epoll_create(2) is no more used.  But since an API
AD>         change has clearly to be excluded, I guess it'll stay as is.
	
AD>         Signed-off-by: Davide Libenzi <davidel at xmailserver.org>
AD>         Signed-off-by: Linus Torvalds <torvalds at osdl.org>
AD> в 2.6.8
AD> <davidel at xmailserver.org>
AD>         [PATCH] epoll: replace the file lookup hash with rbtrees
	
AD>         The epoll allocation for the fd lookup hash used to allocate up to 1MB
AD>         (depending on the "hint" size passed to epoll_create()) with
AD>         __get_free_pages(0), and this might lead to a "malicious" user to do
AD>         something like:
	
AD>             for (i = 0; i < 1024; i++)
AD>                 epoll_create(BIG-NUM);
	
AD>         You can replace "malicious user" with IBM-ltp test suite, and the meaning
AD>         does not change.  The above code might exhaust memory badly, even before
AD>         the file creation limit is topped.  Also, the allocation was independent
AD>         from the number of fds pushed into the epoll fd hash. Using an rb-tree
AD>         ther will be not pre-allocation of the hash, and the size of the memory
AD>         used will be proportional to the number of fds pushed into the epoll fd.
AD>         The patch also removes 100 lines of code, that is never a bad thing ;)
	
AD>         Signed-off-by: Davide Libenzi <davidel at xmailserver.org>
AD>         Signed-off-by: Andrew Morton <akpm at osdl.org>
AD>         Signed-off-by: Linus Torvalds <torvalds at osdl.org>

AD> <js189202 at zodiac.mimuw.edu.pl>
AD>         [PATCH] Fix memory leak in epoll
	
AD>         There was a memory leak in epoll.
	
AD>         The reference count (d_count) of the struct dentry of a new epoll-fd was
AD>         set to TWO.  (new_inode() assigned ONE, than ep_getfd() incremented it by
AD>         dget()).  There was only ONE reference to this dentry, so struct dentry and
AD>         struct inode were never freed.
	
AD>         Signed-off-by: Davide Libenzi <davidel at xmailserver.org>
AD>         Signed-off-by: Andrew Morton <akpm at osdl.org>
AD>         Signed-off-by: Linus Torvalds <torvalds at osdl.org>

AD> думаю что с 2.6.3 до 2.6.8 еще были исправления, поэтому
AD> стоит наверное сначала обновить ядро...




Алексей Бещёков.
proforg at maloletka.ru