Hi,
currently SSL session lifetime and SSL ticket lifetime are equal in
nginx.
If we use session tickets with big enough lifetime (12hrs), we get a lot
of
error log messages while allocating new sessions in shared memory:
2014/03/18 13:36:08 [crit] 18730#0: ngx_slab_alloc() failed: no memory
in
SSL session shared cache “SSL”
We don’t want to increase session cache size b/c working with it is a
blocking operation and I believe it doesn’t work good enought in our
network scheme.
As I can see - those messages are generated by ngx_slab_alloc_pages()
even
if session was added to the cache after expiration of some old ones.
So, what do you think if we add one more config parameter to split
session
cache and session ticket lifetimes?
Thanks.
Regards,
kyprizel.
Hello!
On Tue, Mar 18, 2014 at 03:26:10PM +0400, kyprizel wrote:
blocking operation and I believe it doesn’t work good enought in our
network scheme.
Just a side note: I don’t think that size matters from performance
point of view. The only real downside is memory used.
As I can see - those messages are generated by ngx_slab_alloc_pages() even
if session was added to the cache after expiration of some old ones.
So, what do you think if we add one more config parameter to split session
cache and session ticket lifetimes?
May be better approach will be to just avoid such messages?
–
Maxim D.
http://nginx.org/
What will be the best way to do it?
Hello!
On Tue, Mar 18, 2014 at 03:42:33PM +0400, kyprizel wrote:
What will be the best way to do it?
Probably a flag in ngx_slab_pool_t will be good enough.
nginx.
network scheme.
cache and session ticket lifetimes?
http://mailman.nginx.org/mailman/listinfo/nginx
nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx
–
Maxim D.
http://nginx.org/
Hello!
On Mon, Mar 24, 2014 at 02:59:57PM +0400, kyprizel wrote:
something like this?
Yes, something like. But initialized and with a better name.
Probably a flag in ngx_slab_pool_t will be good enough.
Hi,
SSL session shared cache “SSL”
if session was added to the cache after expiration of some old ones.
–
Maxim D.
http://nginx.org/
nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx
nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx
–
Maxim D.
http://nginx.org/
will be “log_alloc_failures” better?
Any suggestions to the name?
Hello!
On Wed, Mar 26, 2014 at 01:34:19PM +0400, kyprizel wrote:
will be “log_alloc_failures” better?
I think something like “log_nomem” will be good enough.
Patch:
HG changeset patch
Date 1395937285 -14400
Thu Mar 27 20:21:25 2014 +0400
Node ID 2cc8b9fc7efbf6a98ce29f3f860782a1ebd7e6cf
Parent 734f0babfc133c2dc532f2794deadcf9d90245f7
Core: slab log_nomem flag.
The flag allows to suppress “ngx_slab_alloc() failed: no memory”
messages
from a slab allocator, e.g., if an LRU expiration is used by a consumer
and allocation failures aren’t fatal.
The flag is now set in the SSL session cache code, and in the limit_req
module.
diff --git a/src/core/ngx_slab.c b/src/core/ngx_slab.c
— a/src/core/ngx_slab.c
+++ b/src/core/ngx_slab.c
@@ -129,6 +129,7 @@ ngx_slab_init(ngx_slab_pool_t *pool)
pool->pages->slab = pages;
}
- pool->log_nomem = 1;
pool->log_ctx = &pool->zero;
pool->zero = ‘\0’;
}
@@ -658,7 +659,10 @@ ngx_slab_alloc_pages(ngx_slab_pool_t *po
}
}
- ngx_slab_error(pool, NGX_LOG_CRIT, “ngx_slab_alloc() failed: no
memory”);
-
if (pool->log_nomem) {
-
ngx_slab_error(pool, NGX_LOG_CRIT,
-
"ngx_slab_alloc() failed: no memory");
-
}
return NULL;
}
diff --git a/src/core/ngx_slab.h b/src/core/ngx_slab.h
— a/src/core/ngx_slab.h
+++ b/src/core/ngx_slab.h
@@ -39,6 +39,8 @@ typedef struct {
u_char *log_ctx;
u_char zero;
-
unsigned log_nomem:1;
-
void *data;
void *addr;
} ngx_slab_pool_t;
diff --git a/src/event/ngx_event_openssl.c
b/src/event/ngx_event_openssl.c
— a/src/event/ngx_event_openssl.c
+++ b/src/event/ngx_event_openssl.c
@@ -1834,6 +1834,8 @@ ngx_ssl_session_cache_init(ngx_shm_zone_
ngx_sprintf(shpool->log_ctx, " in SSL session shared cache
“%V”%Z",
&shm_zone->shm.name);
-
shpool->log_nomem = 0;
-
return NGX_OK;
}
@@ -1986,7 +1988,7 @@ failed:
ngx_shmtx_unlock(&shpool->mutex);
ngx_log_error(NGX_LOG_ALERT, c->log, 0,
cache");
-
"could not allocate new session%s", shpool->log_ctx);
return 0;
}
diff --git a/src/http/modules/ngx_http_limit_req_module.c
b/src/http/modules/ngx_http_limit_req_module.c
— a/src/http/modules/ngx_http_limit_req_module.c
+++ b/src/http/modules/ngx_http_limit_req_module.c
@@ -451,6 +451,8 @@ ngx_http_limit_req_lookup(ngx_http_limit
node = ngx_slab_alloc_locked(ctx->shpool, size);
if (node == NULL) {
-
ngx_log_error(NGX_LOG_ALERT, ngx_cycle->log, 0,
-
"could not allocate node%s",
ctx->shpool->log_ctx);
return NGX_ERROR;
}
}
@@ -674,6 +676,8 @@ ngx_http_limit_req_init_zone(ngx_shm_zon
ngx_sprintf(ctx->shpool->log_ctx, " in limit_req zone “%V”%Z",
&shm_zone->shm.name);
- ctx->shpool->log_nomem = 0;
- return NGX_OK;
}
–
Maxim D.
http://nginx.org/
Hello!
On Fri, Mar 28, 2014 at 01:33:28PM +0400, kyprizel wrote:
Will this patch be applied to mainline?
Most likely it will, but testing and review are appreciated, as
usual.
@@ -129,6 +129,7 @@ ngx_slab_init(ngx_slab_pool_t *pool)
— a/src/core/ngx_slab.h
diff --git a/src/event/ngx_event_openssl.c b/src/event/ngx_event_openssl.c
b/src/http/modules/ngx_http_limit_req_module.c
}
–
Maxim D.
http://nginx.org/
nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx
nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx
–
Maxim D.
http://nginx.org/
Will this patch be applied to mainline?
On Thursday 27 March 2014 20:23:15 Maxim D. wrote:
The flag is now set in the SSL session cache code, and in the limit_req
pool->log_ctx = &pool->zero;
pool->zero = ‘\0’;
}
Just a quick nitpicking.
I’d suggest to put this log_nomem assignment in the last line as to
follow
order of elements in the structure definition.
wbr, Valentin V. Bartenev
[…]
void *addr;
} ngx_slab_pool_t;
[…]
Hello!
On Fri, Mar 28, 2014 at 11:38:53PM +0400, Valentin V. Bartenev wrote:
HG changeset patch
- pool->log_nomem = 1;
pool->log_ctx = &pool->zero;
pool->zero = ‘\0’;
}
Just a quick nitpicking.
I’d suggest to put this log_nomem assignment in the last line as to follow
order of elements in the structure definition.
IMHO, it looks silly this way, and that’s why it was placed just
before the log_ctx assignment.
Note well that the order of elements in the structure is more
about memory efficiency, and following the order isn’t something
required.
–
Maxim D.
http://nginx.org/
Hello,
From http://tools.ietf.org/html/rfc5077#section-3.4, I think Session
Tickets
and Session ID do not work for one connection at the same time. If the
client supports Tickets, then Session ID (or the session cache) will not
work.
Am I right? In my test, the 2 callbacks ngx_ssl_new_session() and
ngx_ssl_get_cached_session() are not called if ticket is used.
So if we assume that most browsers support Tickets now, the session
cache
does not work at most time, why does the ngx_slab_alloc() fails in your
post?
If I am right, should I just disable session cache, and set tickets life
time big enough?
Maybe SSL_CTX_set_timeout() should be moved to the beginning of
ngx_ssl_session_cache() then.
Thanks
Wu
–
View this message in context:
http://nginx.2469901.n2.nabble.com/SSL-session-cache-lifetime-vs-session-ticket-lifetime-tp7588963p7590693.html
Sent from the nginx mailing list archive at Nabble.com.
Hey,
Maybe SSL_CTX_set_timeout() should be moved to the beginning of
ngx_ssl_session_cache() then.
http://hg.nginx.org/nginx/rev/767aa37f12de
Best regards,
Piotr S.