Hello!

On Sat, Nov 11, 2017 at 08:36:18AM -0500, S.A.N wrote:

> Maxim Dounin Wrote:
> -------------------------------------------------------
> > Я, впрочем, подозреваю, что на самом деле там не это, а то, что
> > лежит по адресу https://github.com/jtkukunas/zlib. Название и
> > содержимое пакета как бы намекает:
> >
> > https://download.clearlinux.org/current/source/SRPMS/zlib-1.2.8.jtkv4-
> > 40.src.rpm
>
> Вы правы, в OS ClearLinux библеотека zlib из этого пакета и там нет
> константы Z_IPP_FAST_COMPRESSION.
> Я написал им issue, чтобы они добавили константу, но сомневаюсь что в
> ближайшем будущем они что-то сделают, хотя.
>
> Может быть сделать спец флаг компиляции Nginx ./configure --with-ipp-zlib
> Как уже предлагали в этой ветке
> https://forum.nginx.org/read.php?2,252113,252114#msg-252114
>
> Тогда мейнтейнеры смогут создавать свои сборки Nginx с 3rd party zlib.
> Этот вариант для вас приемлем?

Это не выглядит хорошим решением. Особенно с учётом того, что IPP
zlib и jtk zlib - это два разных zlib'а.

> > Уровень логгирования alert означает ситуацию, которая не должна
> > возникать при нормальной работе, и означает ошибку где-то. В
> > данном случае мы знаем причину - библиотека от Интел нарушает
> > документированный интерфейс zlib в части требований к памяти - и
> > этого достаточно для того, чтобы игнорировать и/или понизить
> > уровень ошибки до менее значительного в случае использования
> > этой библиотеки. Однако я бы предпочёл не трогать уровень
> > логгирования для всех остальных случаев.
>
> Я согласен с вашими словами, но я ничего не понял что нужно мне сделать,
> чтобы в логах не было этой ошибки?
> В конфиге отключить логирование этого alert можно только если указать
> уровень логирование emerge
> error_log log/error.log emerge;
> Но это не хорошо, мягко говоря, или вы имели виду чтобы я сделал свой патч и
> изменил в коде Nginx уровень логирование?

Патч ниже по первой ошибке преаллокации пытается предполагать, что
мы работаем с jtk zlib, и работает соответственно. Если и это не
помогло - тогда уже начинает писать в лог alert'ы.

# HG changeset patch
# User Maxim Dounin <mdounin@mdounin.ru>
# Date 1510720355 -10800
# Wed Nov 15 07:32:35 2017 +0300
# Node ID 63b85af82bb1ad8b7d29979619b22ecebd962c66
# Parent 9ba0a577601b7c1b714eb088bc0b0d21c6354699
Gzip: support for a zlib variant from Intel.

A zlib variant from Intel as available from https://github.com/jtkukunas/zlib
uses 64K hash instead of scaling it from the specified memory level, and
also uses 16-byte padding in one of the window-sized memory buffers, and can
force window bits to 13 if compression level is set to 1 and appropriate
compile options are used. As a result, nginx complained with "gzip filter
failed to use preallocated memory" alerts.

This change improves deflate_state allocation detection by testing that
items is 1 (deflate_state is the only allocation where items is 1).
Additionally, on first failure to use preallocated memory we now assume
that we are working with the Intel's modified zlib, and switch to using
appropriate preallocations. If this does not help, we complain with the
usual alerts.

Previous version of this patch was published at
http://mailman.nginx.org/pipermail/nginx/2014-July/044568.html.
The zlib variant in question is used by default in ClearLinux from Intel,
see http://mailman.nginx.org/pipermail/nginx-ru/2017-October/060421.html,
http://mailman.nginx.org/pipermail/nginx-ru/2017-November/060544.html.

diff --git a/src/http/modules/ngx_http_gzip_filter_module.c b/src/http/modules/ngx_http_gzip_filter_module.c
--- a/src/http/modules/ngx_http_gzip_filter_module.c
+++ b/src/http/modules/ngx_http_gzip_filter_module.c
@@ -57,6 +57,7 @@ typedef struct {
unsigned nomem:1;
unsigned gzheader:1;
unsigned buffering:1;
+ unsigned intel:1;

size_t zin;
size_t zout;
@@ -233,6 +234,8 @@ static ngx_str_t ngx_http_gzip_ratio =
static ngx_http_output_header_filter_pt ngx_http_next_header_filter;
static ngx_http_output_body_filter_pt ngx_http_next_body_filter;

+static ngx_uint_t ngx_http_gzip_assume_intel;
+

static ngx_int_t
ngx_http_gzip_header_filter(ngx_http_request_t *r)
@@ -527,7 +530,27 @@ ngx_http_gzip_filter_memory(ngx_http_req
* *) 5920 bytes on amd64 and sparc64
*/

- ctx->allocated = 8192 + (1 << (wbits + 2)) + (1 << (memlevel + 9));
+ if (!ngx_http_gzip_assume_intel) {
+ ctx->allocated = 8192 + (1 << (wbits + 2)) + (1 << (memlevel + 9));
+
+ } else {
+ /*
+ * A zlib variant from Intel, https://github.com/jtkukunas/zlib.
+ * It can force window bits to 13 for fast compression level,
+ * on processors with SSE 4.2 it uses 64K hash instead of scaling
+ * it from the specified memory level, and also introduces
+ * 16-byte padding in one out of the two window-sized buffers.
+ */
+
+ if (conf->level == 1) {
+ wbits = ngx_max(wbits, 13);
+ }
+
+ ctx->allocated = 8192 + 16 + (1 << (wbits + 2))
+ + (1 << (ngx_max(memlevel, 8) + 8))
+ + (1 << (memlevel + 8));
+ ctx->intel = 1;
+ }
}


@@ -1003,7 +1026,7 @@ ngx_http_gzip_filter_alloc(void *opaque,

alloc = items * size;

- if (alloc % 512 != 0 && alloc < 8192) {
+ if (items == 1 && alloc % 512 != 0 && alloc < 8192) {

/*
* The zlib deflate_state allocation, it takes about 6K,
@@ -1025,9 +1048,14 @@ ngx_http_gzip_filter_alloc(void *opaque,
return p;
}

- ngx_log_error(NGX_LOG_ALERT, ctx->request->connection->log, 0,
- "gzip filter failed to use preallocated memory: %ud of %ui",
- items * size, ctx->allocated);
+ if (ctx->intel) {
+ ngx_log_error(NGX_LOG_ALERT, ctx->request->connection->log, 0,
+ "gzip filter failed to use preallocated memory: "
+ "%ud of %ui", items * size, ctx->allocated);
+
+ } else {
+ ngx_http_gzip_assume_intel = 1;
+ }

p = ngx_palloc(ctx->request->pool, items * size);


--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru