I've been running a node with this patch on a production machine for 5 days and
am seeing marked improvements. The instance hasn't needed to be restarted
due to "ngx_slab_alloc() failed: no memory". The shared memory usage has been
growing at a far slower rate compared to a node without the patch.
Also, not seeing any significant increase in CPU usage.

nginx/1.2.9
Mixture of HTTP/HTTPS traffic
400,000 to 700,000 concurrent connections
Linux 3.2.0-40-generic x86_64

It's a dedicated instance for Wandenberg's
https://github.com/wandenberg/nginx-push-stream-module

On Tue, Aug 6, 2013 at 1:19 PM, Wandenberg Peixoto <wandenberg@gmail.com> wrote:
>
> Hello!
>
> Thanks for your help. I hope that the patch be OK now.
> I don't know if the function and variable names are on nginx pattern.
> Feel free to change the patch.
> If you have any other point before accept it, will be a pleasure to fix it.
>
>
> --- src/core/ngx_slab.c 2013-05-06 07:27:10.000000000 -0300
> +++ src/core/ngx_slab.c 2013-07-31 00:21:08.043034442 -0300
> @@ -615,6 +615,26 @@ fail:
>
>
> static ngx_slab_page_t *
> +ngx_slab_merge_with_neighbour(ngx_slab_pool_t *pool, ngx_slab_page_t *page)
> +{
>
> + ngx_slab_page_t *neighbour = &page[page->slab];
> + if (((ngx_slab_page_t *) neighbour->prev != NULL) && (neighbour->next != NULL) && ((neighbour->prev & NGX_SLAB_PAGE_MASK) == NGX_SLAB_PAGE)) {
> + page->slab += neighbour->slab;
>
> +
> + ((ngx_slab_page_t *) neighbour->prev)->next = neighbour->next;
> + neighbour->next->prev = neighbour->prev;
> +
> + neighbour->slab = NGX_SLAB_PAGE_FREE;
> + neighbour->prev = (uintptr_t) &pool->free;
> + neighbour->next = &pool->free;
> +
> + return page;
> + }
> + return NULL;
> +}
> +
> +
> +static ngx_slab_page_t *
> ngx_slab_alloc_pages(ngx_slab_pool_t *pool, ngx_uint_t pages)
> {
> ngx_slab_page_t *page, *p;
> @@ -657,6 +677,19 @@ ngx_slab_alloc_pages(ngx_slab_pool_t *po
> }
> }
>
> + ngx_flag_t retry = 0;
> + for (page = pool->free.next; page != &pool->free;) {
> + if (ngx_slab_merge_with_neighbour(pool, page)) {
> + retry = 1;
> + } else {
> + page = page->next;
> + }
> + }
> +
> + if (retry) {
> + return ngx_slab_alloc_pages(pool, pages);
> + }
> +
> ngx_slab_error(pool, NGX_LOG_CRIT, "ngx_slab_alloc() failed: no memory");
>
> return NULL;
> @@ -687,6 +720,8 @@ ngx_slab_free_pages(ngx_slab_pool_t *poo
>
> page->next->prev = (uintptr_t) page;
>
> pool->free.next = page;
> +
> + ngx_slab_merge_with_neighbour(pool, page);
> }
>
>
>
>
>
>
> On Tue, Jul 30, 2013 at 7:09 AM, Maxim Dounin <mdounin@mdounin.ru> wrote:
>>
>> Hello!
>>
>> On Mon, Jul 29, 2013 at 04:01:37PM -0300, Wandenberg Peixoto wrote:
>>
>> [...]
>>
>> > What would be an alternative to not loop on pool->pages?
>>
>> Free memory blocks are linked in pool->free list, it should be
>> enough to look there.
>>
>> [...]
>>
>> --
>> Maxim Dounin
>> http://nginx.org/en/donation.html
>>
>> _______________________________________________
>> nginx-devel mailing list
>> nginx-devel@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
>
>

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel