Forum: NGINX ngx_slab_alloc() failed: no memory in cache keys zone "zone-xyz"

623c3eb9c36f7756310312476bf4a44d?d=identicon&s=25 praveenkumar Muppala (Guest)
on 2013-03-27 13:35
(Received via mailing list)
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.
B06eb1010fe1ac013d977a06e729380d?d=identicon&s=25 flygoast (Guest)
on 2013-03-28 13:14
(Received via mailing list)
Did you tune the shared memory size in proxy_cache_path?





At 2013-03-27 20:34:27,"praveenkumar Muppala" <pravinmuppala@gmail.com>
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.
40b4c848b8fcd63b0cb60b9d170c3a77?d=identicon&s=25 Valentin V. Bartenev (Guest)
on 2013-03-28 15:32
(Received via mailing list)
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
2974d09ac2541e892966b762aad84943?d=identicon&s=25 nxspeed (Guest)
on 2014-03-24 20:07
(Received via mailing list)
> 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:
http://forum.nginx.org/read.php?2,237829,248642#msg-248642
2974d09ac2541e892966b762aad84943?d=identicon&s=25 jakubp (Guest)
on 2014-04-01 02:14
(Received via mailing list)
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)
{
// <snip>
        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:
http://forum.nginx.org/read.php?2,237829,248885#msg-248885
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2014-04-01 14:33
(Received via mailing list)
Hello!

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

> // <snip>
>         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 Dounin
http://nginx.org/
2974d09ac2541e892966b762aad84943?d=identicon&s=25 jakubp (Guest)
on 2014-04-02 11:31
(Received via mailing list)
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:
http://forum.nginx.org/read.php?2,237829,248913#msg-248913
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2014-04-02 14:21
(Received via mailing list)
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
http://nginx.org/r/proxy_cache_path).  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 Dounin
http://nginx.org/
2974d09ac2541e892966b762aad84943?d=identicon&s=25 jakubp (Guest)
on 2014-04-03 01:41
(Received via mailing list)
> What currently can be used for such a use case is "inactive="
> parameter of the proxy_cache_path directive (see
> http://nginx.org/r/proxy_cache_path).  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:
http://forum.nginx.org/read.php?2,237829,248946#msg-248946
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2014-04-03 13:34
(Received via mailing list)
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 Dounin
http://nginx.org/
2974d09ac2541e892966b762aad84943?d=identicon&s=25 jakubp (Guest)
on 2014-05-08 23:55
(Received via mailing list)
> 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:
http://forum.nginx.org/read.php?2,237829,249945#msg-249945
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.