Ngx_slab_alloc() failed: no memory in cache keys zone "zone-xyz"

Server NGINX
1

Hi,

We have a nginx1.0.5 version installed in our system. We are getting
this
error continuously in our nginx error log. ngx_slab_alloc() failed: no
memory in cache keys zone “zone-xyz”. I have increased this value to
20G,
even 30G also still getting the same error. Can you help to fix this
error
please.

2

Did you tune the shared memory size in proxy_cache_path?

At 2013-03-27 20:34:27,“praveenkumar Muppala” [email protected]
wrote:
Hi,

We have a nginx1.0.5 version installed in our system. We are getting
this error continuously in our nginx error log. ngx_slab_alloc() failed:
no memory in cache keys zone “zone-xyz”. I have increased this value to
20G, even 30G also still getting the same error. Can you help to fix
this error please.

3

On Wednesday 27 March 2013 16:34:27 praveenkumar Muppala wrote:

Hi,

We have a nginx1.0.5 version installed in our system. We are getting this
error continuously in our nginx error log. ngx_slab_alloc() failed: no
memory in cache keys zone “zone-xyz”. I have increased this value to 20G,
even 30G also still getting the same error. Can you help to fix this error
please.

Do you really have 30 gigabytes of RAM? Why do you need such a big zone?

You are probably confuse “keys_zone” with max cache size.

wbr, Valentin V. Bartenev

–
http://nginx.org/en/donation.html

4

error

please.

Do you really have 30 gigabytes of RAM? Why do you need such a big
zone?

You are probably confuse “keys_zone” with max cache size.

wbr, Valentin V. Bartenev

Does ngx_http_file_cache_manager() actively manage the size of the
‘keys_zone’? i.e., will the manager remove old items from cache to keep
the
keys_zone under its configured size?

Posted at Nginx Forum:

5

Hi

I am struggling with the very same issue at the moment…

If I read the right the code correctly all that nginx cares about is
cache
size, keys zone size is not checked at all (except when more space needs
to
be allocated).

ngx_http_file_cache_manager(void *data)
{
//
if (size < cache->max_size) {
return next;
}

    wait = ngx_http_file_cache_forced_expire(cache);

Are there any plans to monitor keys zone size and remove a chunk of LRU
keys
if it’s close to being full?

Rgds
Jakub

Posted at Nginx Forum:

6

Hello!

On Mon, Mar 31, 2014 at 08:13:20PM -0400, jakubp wrote:

//
if (size < cache->max_size) {
return next;
}

    wait = ngx_http_file_cache_forced_expire(cache);

Are there any plans to monitor keys zone size and remove a chunk of LRU keys
if it’s close to being full?

Isn’t max_size and inactive work for you?

–
Maxim D.
http://nginx.org/

7

Hello!

On Wed, Apr 02, 2014 at 05:30:55AM -0400, jakubp wrote:

Hi Maxim

Let me explain the use case.
I am using cache module to serve very large library. Some files are very
popular but a ot of them are not popular at all though. To deal with this
long tail I use proxy_cache_min_uses to cache only after it was requested
several times. So what I think happens is that disk is not a limiting factor
(at least not enough) but keys zone grows very quickly.

What currently can be used for such a use case is “inactive=”
parameter of the proxy_cache_path directive (see
Module ngx_http_proxy_module). It ensures that items not
recently requested are removed from the cache, including ones
created with proxy_cache_min_uses. Have you tried tuning it?

–
Maxim D.
http://nginx.org/

8

What currently can be used for such a use case is “inactive=”
parameter of the proxy_cache_path directive (see
Module ngx_http_proxy_module). It ensures that items not
recently requested are removed from the cache, including ones
created with proxy_cache_min_uses. Have you tried tuning it?

Hi Maxim

Thank you for your response.
Yes, that is what I do - try to keep balance between inactive time
(which I
obviously want to keep as high as possible) and the keys zone size. But
this
is constant/never-ending effort if the traffic pattern is changing (and
it
unfortunately is for me…). It would be great if nginx used keys size
as an
additional trigger to forced_expire resources - to auto-adjust the
removal
aggression when the traffic profile changes.

Regards,
Kuba

Posted at Nginx Forum:

9

Hello!

On Wed, Apr 02, 2014 at 07:41:13PM -0400, jakubp wrote:

obviously want to keep as high as possible) and the keys zone size. But this
In most cases, it doesn’t make sense to keep inactive time high.
If something isn’t requested often enough, it may be better to
remove it from cache.

is constant/never-ending effort if the traffic pattern is changing (and it
unfortunately is for me…). It would be great if nginx used keys size as an
additional trigger to forced_expire resources - to auto-adjust the removal
aggression when the traffic profile changes.

It does so - if an allocation of a cache node fails, this will
trigger a forced expiration of a cache node, and then tries to
allocate a node again. This is more an emergency mechanism
though (and not guaranteed to work, as another allocation may
fail, too), hence alerts are logged in such cases.

Recently, it was made possible to avoid slab allocation failures
logging, and this is now used by SSL session cache code, as well
as limit_req module[1]. This mechanism may be used by proxy_cache
to avoid logging, too, yet I’m not yet convinced it actually
should.

[1] http://hg.nginx.org/nginx/rev/5024d29354f1

–
Maxim D.
http://nginx.org/

10

It does so - if an allocation of a cache node fails, this will
trigger a forced expiration of a cache node, and then tries to
allocate a node again. This is more an emergency mechanism
though (and not guaranteed to work, as another allocation may
fail, too), hence alerts are logged in such cases.

Thanks for the information. It indeed helps my use case. For now I’ll
disable the meassges.

Kuba

Posted at Nginx Forum:

11

Hi Maxim

Let me explain the use case.
I am using cache module to serve very large library. Some files are very
popular but a ot of them are not popular at all though. To deal with
this
long tail I use proxy_cache_min_uses to cache only after it was
requested
several times. So what I think happens is that disk is not a limiting
factor
(at least not enough) but keys zone grows very quickly.

Thanks,
Kuba

Posted at Nginx Forum: