Help with shared memory usage

[John Watson]

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 at 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 at 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 at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
>
>