странности в работе nginx

[Artem Danilenko]

-----Original Message-----
From: Igor Sysoev <is at rambler-co.ru>
To: nginx-ru at sysoev.ru
Date: Mon, 25 Apr 2005 10:30:49 +0400 (MSD)
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 ?

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

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

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