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

[Artem Danilenko <darkden@xxxxxxx>]

-----Original Message-----
From: Igor Sysoev <is@xxxxxxxxxxxxx>
To: nginx-ru@xxxxxxxxx
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@xxxxxxxxxxxxxxx>
        [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@xxxxxxxxxxxxxxx>
        Signed-off-by: Linus Torvalds <torvalds@xxxxxxxx>
в 2.6.8
<davidel@xxxxxxxxxxxxxxx>
        [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@xxxxxxxxxxxxxxx>
        Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
        Signed-off-by: Linus Torvalds <torvalds@xxxxxxxx>

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

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