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

[Alexey Bestciokov <proforg@xxxxxxxxxxxx>]

ядро последнее из стабильной ветки - 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@xxxxxxxxxxxxx>
AD> To: nginx-ru@xxxxxxxxx
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@xxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx>
AD>         Signed-off-by: Linus Torvalds <torvalds@xxxxxxxx>
AD> в 2.6.8
AD> <davidel@xxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx>
AD>         Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
AD>         Signed-off-by: Linus Torvalds <torvalds@xxxxxxxx>

AD> <js189202@xxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx>
AD>         Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
AD>         Signed-off-by: Linus Torvalds <torvalds@xxxxxxxx>

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




Алексей Бещёков.
proforg@xxxxxxxxxxxx