Re: nginx: [emerg] getpwnam("www-data") failed
Hello! On Mon, Apr 08, 2019 at 03:48:30AM +0300, Maxim Dounin wrote: > On Sat, Apr 06, 2019 at 01:21:06PM +0100, Anton Kiryushkin wrote: > > > При обновлении на 1.15.10 поймал такую картину. В конфиге полжизни было > > написано: > > user www-data; > > > > Пользователь есть, группа есть. Все ищется по /etc/passwd и /etc/group. Что > > поменялось в nginx? > > Ничего. Последнее изменение в соответствующей функции - > стилистическое - датируется 2015 годом, nginx 1.9.6, 7ac57369036c. > Последнее смысловое изменение - о том, чтобы сообщения об ошибках > были более детерминированы - было в 2007 году, nginx 0.6.3, > eb232400e829. > > Сообщение как бы говорит о том, что библиотечный вызов > getpwnam() с параметром "www-data" вернул ошибку. Если далее в > скобках не указано подробностей про собственно ошибку - это должно > случаться тогда и только тогда, когда такого пользователя нет. > Если это не соответствует реальности - стоит искать причины в > системе. Соседний тред наводит на мысли о том, что nginx собран на Linux'е статически. В этом случае линковщик выдаёт большую простыню warning'ов, в том числе - про getpwnam(): warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking Если это требование нарушено - чудеса ожидаемы. На практике это означает, что статически собранное приложение можно использовать только на той же машине и необходимо пересобирать при любых обновлениях системы. Ну или просто не надо ничего собирать статически. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Статическая сборка nginx с GD
Hello!
On Sun, Apr 07, 2019 at 10:41:22PM +0300, Igor Sysoev wrote:
> > On 7 Apr 2019, at 22:16, Anton Kiryushkin wrote:
> >
> > Я взял код из лога и попробовал его собрать ровно так, как написано.
> > Строка моего configure следующая:
> > ./configure --prefix=/usr --conf-path=/etc/nginx/nginx.conf
> > --error-log-path=/var/log/nginx/error.log
> > --http-client-body-temp-path=/var/lib/nginx/body
> > --http-fastcgi-temp-path=/var/lib/nginx/fastcgi
> > --http-log-path=/var/log/nginx/access.log
> > --http-proxy-temp-path=/var/lib/nginx/proxy
> > --http-scgi-temp-path=/var/lib/nginx/scgi
> > --http-uwsgi-temp-path=/var/lib/nginx/uwsgi
> > --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug
> > --with-http_addition_module --with-http_dav_module --with-http_geoip_module
> > --with-http_gzip_static_module --with-http_realip_module
> > --with-http_stub_status_module --with-http_ssl_module
> > --with-http_sub_module --with-sha1=/usr/include/openssl
> > --with-md5=/usr/include/openssl --add-module=/usr/src/naxsi/naxsi_src
> > --with-debug --with-http_v2_module --with-cc-opt="-static -static-libgcc"
> > --with-ld-opt="-static -lm" --with-cpu-opt=generic
> > --with-openssl=./openssl-1.0.2r --with-stream --with-stream_ssl_module
> > --user=www-data --with-http_image_filter_module
> >
> > Что-то тут уже устаревшее, но это не очень важно.
> > Выпадает ошибка:
> > checking for GD library ... not found
> > checking for GD library in /usr/local/ ... not found
> > checking for GD library in /usr/pkg/ ... not found
> > checking for GD library in /opt/local/ ... not found
> >
> > Окей. Берем код автотеста:
> >
> > #include
> > #include
> > #include
> >
> > int main(void) {
> > gdImagePtr img = gdImageCreateFromGifPtr(1, NULL);
> > (void) img;
> > return 0;
> > }
> >
> > Собираем:
> > cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I
> > /usr/pkg/include -o objs/autotest objs/autotest.c -static -lm
> > -L/usr/pkg/lib -lgd (строчка из того же лога).
> > Не собирается.
> > Однако, если подвинуть -lm в конец:
> > cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I
> > /usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib
> > -lgd -lm
> >
> > Все соберется.
> >
> > Вопрос, как передвинуть на уровне сборки?
>
> Штатно не двигается.
> Можно добавить в auto/lib/libgd/conf:
>
> - ngx_feature_libs="-L/usr/pkg/lib -lgd"
> + ngx_feature_libs="-L/usr/pkg/lib -lgd -lm"
>
> В динамической libgd.so зависимость от libm.so записана,
> а в статической такой возможности нет.
Штатно аналогичный результат можно, если очень хочется, получить так:
./configure --with-http_image_filter_module \
--with-ld-opt="-L/usr/pkg/lib -static -lgd -lm"
Хотя вот лично я бы - не рекомендовал, особенно под Linux'ом. Там
warning'и при статической линковке - не просто так, и
игнорирование их ведёт к вопросам "у меня всё сломалось, что вы
поменяли в nginx'е" вполне очевидным образом.
Тем более, что у современного GD зависимостей - устанешь
перечислять, -lm - это только верхушка айсберга. Скажем, чтобы
собраться статически со штатным пакетом GD на FreeBSD мне
потребовалась какая-то такая простыня:
./auto/configure --with-http_image_filter_module \
--with-ld-opt="-L/usr/local/lib -static -lgd -lm \
-lpng -lm -lz -lfontconfig -lfreetype -ljpeg \
-ltiff -lwebp -lexpat -lbz2"
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx: [emerg] getpwnam("www-data") failed
Hello! On Sat, Apr 06, 2019 at 01:21:06PM +0100, Anton Kiryushkin wrote: > При обновлении на 1.15.10 поймал такую картину. В конфиге полжизни было > написано: > user www-data; > > Пользователь есть, группа есть. Все ищется по /etc/passwd и /etc/group. Что > поменялось в nginx? Ничего. Последнее изменение в соответствующей функции - стилистическое - датируется 2015 годом, nginx 1.9.6, 7ac57369036c. Последнее смысловое изменение - о том, чтобы сообщения об ошибках были более детерминированы - было в 2007 году, nginx 0.6.3, eb232400e829. Сообщение как бы говорит о том, что библиотечный вызов getpwnam() с параметром "www-data" вернул ошибку. Если далее в скобках не указано подробностей про собственно ошибку - это должно случаться тогда и только тогда, когда такого пользователя нет. Если это не соответствует реальности - стоит искать причины в системе. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: https cpu load
вс, 7 апр. 2019 г. в 23:22, Slawa Olhovchenkov : > On Sun, Apr 07, 2019 at 11:12:50PM +0500, Илья Шипицин wrote: > > > > > естественно. я предполагаю, что тот, кто будет сравнивать, понимает > это. > > > > > > и при этом не сообщая ничего о своем (референсном в данном случае) > > > профиле нагрузке? оригинально > > > > > > > это некое предположение, что "среднее хорошо написанное веб-приложение > для > > браузера" работает примерно одинаково. > > я не заметил, там говорилось что нгинкс колокейтится с приложением? > он не статику раздает, не проксей работает? > > > > > > > > > > > > > > > > > > > > > Вообще, я с вами согласен, моё предложение посмотреть профайлер > было > > > как > > > > > > раз про это. > > > > > > > > > > нет никакого смысла смотреть профайлер в данный момент. > > > > > > > > > > > > > в любом случае, чтобы узнать, на что расходуется cpu, надо смотреть > > > > профайлер. какие еще есть варианты ? > > > > > > очевидно он расходуется на https, это бесполезное знание. > > > > > > > > > неочевидно. > > например, у нас 70% cpu это компрессия. > > > > опять же, https это как минимум два вида нагрузки - ассиметричные > хендшейки > > и симметричное шифрование. сколько каждого из них, весьма интересно. > > это бесполезное знание, пока мы не узнали что на это расходуется > больше ожидаемого. если у нас большая частота новых соединений то > будет пик в ассиметричных хендшейках и что дальше? так и должно быть. > информация о том, что пик в хендшейках - полезна. допустим, у нас не используется http2 - значит надо его включить допустим, можно увеличить keepalive_requests допустим, можно поревьювить кеш SSL сессий (хотя, по приведенному конфигу - с ним все хорошо) допустим, можно поменять порядок шифрстютов (у GCM хендшейки дешевле) допустим, можно перейти на ECDSA (увеличение производительности от x4 на Xeon до x16 на Celeron) > и смотреть надо на это для начала, а не профайлинг запускать. > без профайлинга непонятно, действительно ли ssl в топе. > > да и вообще, поинтересоваться что за процессор и все такое. > > > из интересных моментов, каким-то странным образом при сборке портов > > freebsd, мы умудрились скомпилировать openssl с выключенной ассемблерной > > оптимизацией. > > это надо было постараться, да. > даже дважды (т.е. что бы для начала системный не устроил) > на freebsd до недавнего времени в base system поставлвлся openssl-1.0.1, постарались мы ровно один раз, когда "убрали" галочку с ассемблерной оптимизации > > > по профайлеру увидели, что 25% cpu уходит на "big numbers" арифметику > > (которая в случае включенной ассемблерной оптимизации умножилась на > ноль). > > > > еще из интересных моментов, был странный опыт с подменой ответа (какой-то > > баг чинили), вылилось это в то, что раздача инсталяторов (при обновлении > > тимсити) привела к всплеску cpu. увидели это тоже по gperftools > > это проявлялось тоьлко на https? > это пример того, как при помощи профайлера найти узкое место. проявлялось это, понятно, в единственной ситуации, вышел новый релиз teamcity, и несколько десятков агентов пошли скачивать инсталяторы. и это пошло сквозь регурярку > > > сколько раз использовал gperftools, еще не было повода пожалеть. > > ни разу не использовал и не жалею. > предпочитаю pcstat, но тогда когда имеет смысл. > вариантов профилирования миллион. неплохой обзор, например, тут http://openresty.org/slides/nginx-conf-2018/#1 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Статическая сборка nginx с GD
> On 7 Apr 2019, at 22:16, Anton Kiryushkin wrote:
>
> Я взял код из лога и попробовал его собрать ровно так, как написано.
> Строка моего configure следующая:
> ./configure --prefix=/usr --conf-path=/etc/nginx/nginx.conf
> --error-log-path=/var/log/nginx/error.log
> --http-client-body-temp-path=/var/lib/nginx/body
> --http-fastcgi-temp-path=/var/lib/nginx/fastcgi
> --http-log-path=/var/log/nginx/access.log
> --http-proxy-temp-path=/var/lib/nginx/proxy
> --http-scgi-temp-path=/var/lib/nginx/scgi
> --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock
> --pid-path=/var/run/nginx.pid --with-debug --with-http_addition_module
> --with-http_dav_module --with-http_geoip_module
> --with-http_gzip_static_module --with-http_realip_module
> --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module
> --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl
> --add-module=/usr/src/naxsi/naxsi_src --with-debug --with-http_v2_module
> --with-cc-opt="-static -static-libgcc" --with-ld-opt="-static -lm"
> --with-cpu-opt=generic --with-openssl=./openssl-1.0.2r --with-stream
> --with-stream_ssl_module --user=www-data --with-http_image_filter_module
>
> Что-то тут уже устаревшее, но это не очень важно.
> Выпадает ошибка:
> checking for GD library ... not found
> checking for GD library in /usr/local/ ... not found
> checking for GD library in /usr/pkg/ ... not found
> checking for GD library in /opt/local/ ... not found
>
> Окей. Берем код автотеста:
>
> #include
> #include
> #include
>
> int main(void) {
> gdImagePtr img = gdImageCreateFromGifPtr(1, NULL);
> (void) img;
> return 0;
> }
>
> Собираем:
> cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I
> /usr/pkg/include -o objs/autotest objs/autotest.c -static -lm -L/usr/pkg/lib
> -lgd (строчка из того же лога).
> Не собирается.
> Однако, если подвинуть -lm в конец:
> cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I
> /usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib -lgd
> -lm
>
> Все соберется.
>
> Вопрос, как передвинуть на уровне сборки?
Штатно не двигается.
Можно добавить в auto/lib/libgd/conf:
- ngx_feature_libs="-L/usr/pkg/lib -lgd"
+ ngx_feature_libs="-L/usr/pkg/lib -lgd -lm"
В динамической libgd.so зависимость от libm.so записана,
а в статической такой возможности нет.
--
Igor Sysoev
http://nginx.com
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Статическая сборка nginx с GD
Я взял код из лога и попробовал его собрать ровно так, как написано.
Строка моего configure следующая:
./configure --prefix=/usr --conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log
--http-client-body-temp-path=/var/lib/nginx/body
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi
--http-log-path=/var/log/nginx/access.log
--http-proxy-temp-path=/var/lib/nginx/proxy
--http-scgi-temp-path=/var/lib/nginx/scgi
--http-uwsgi-temp-path=/var/lib/nginx/uwsgi
--lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug
--with-http_addition_module --with-http_dav_module --with-http_geoip_module
--with-http_gzip_static_module --with-http_realip_module
--with-http_stub_status_module --with-http_ssl_module
--with-http_sub_module --with-sha1=/usr/include/openssl
--with-md5=/usr/include/openssl --add-module=/usr/src/naxsi/naxsi_src
--with-debug --with-http_v2_module --with-cc-opt="-static -static-libgcc"
--with-ld-opt="-static -lm" --with-cpu-opt=generic
--with-openssl=./openssl-1.0.2r --with-stream --with-stream_ssl_module
--user=www-data --with-http_image_filter_module
Что-то тут уже устаревшее, но это не очень важно.
Выпадает ошибка:
checking for GD library ... not found
checking for GD library in /usr/local/ ... not found
checking for GD library in /usr/pkg/ ... not found
checking for GD library in /opt/local/ ... not found
Окей. Берем код автотеста:
#include
#include
#include
int main(void) {
gdImagePtr img = gdImageCreateFromGifPtr(1, NULL);
(void) img;
return 0;
}
Собираем:
cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I
/usr/pkg/include -o objs/autotest objs/autotest.c -static -lm
-L/usr/pkg/lib -lgd (строчка из того же лога).
Не собирается.
Однако, если подвинуть -lm в конец:
cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I
/usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib
-lgd -lm
Все соберется.
Вопрос, как передвинуть на уровне сборки?
вс, 7 апр. 2019 г. в 12:34, Anton Kiryushkin :
> Да, конечно, есть:
>
> # find /usr -type f -name 'libm.a'
> /usr/lib/x86_64-linux-gnu/libm.a
>
> Да, я попробовал поставить -lm перед -static, это мне тоже не помогло.
> К слову, libgd тоже там есть:
> # find /usr -type f -name 'libgd.a'
> /usr/lib/x86_64-linux-gnu/libgd.a
>
> Подскажите, пожалуйста, где эти тесты лежат в исходнике, поправлю
> локально, как обычно это делаю с php.
>
> сб, 6 апр. 2019 г. в 19:22, Igor Sysoev :
>
>> А статическая libm.a есть?
>> Можно попробовать поставить -lm до -static:
>>
>> --with-ld-opt="-lm -static ...
>>
>> --
>> Igor Sysoev
>> http://nginx.com
>>
>> > On 6 Apr 2019, at 14:57, Anton Kiryushkin wrote:
>> >
>> > Ситуация очень напоминает предыдущую:
>> >
>> > cc -static -static-libgcc -lm -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I
>> /usr/pkg/include -o objs/autotest objs/autotest.c -static -lm
>> -L/usr/pkg/lib -lgd
>> > --
>> >
>> >
>> > checking for GD library in /opt/local/
>> >
>> > /opt/local/lib/libgd.a(gd.o): In function `lsqrt':
>> > /usr/src/libgd/src/gd.c:1722: undefined reference to `sqrt'
>> > /opt/local/lib/libgd.a(gd.o): In function `gdImageDashedLine':
>> > /usr/src/libgd/src/gd.c:1471: undefined reference to `atan2'
>> > /usr/src/libgd/src/gd.c:1471: undefined reference to `sin'
>> > /usr/src/libgd/src/gd.c:1520: undefined reference to `atan2'
>> > /usr/src/libgd/src/gd.c:1520: undefined reference to `sin'
>> > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine':
>> > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2'
>> > /usr/src/libgd/src/gd.c:3514: undefined reference to `cos'
>> > /opt/local/lib/libgd.a(gd.o): In function `gdImageLine':
>> > /usr/src/libgd/src/gd.c:1394: undefined reference to `atan2'
>> > /usr/src/libgd/src/gd.c:1394: undefined reference to `sin'
>> > /usr/src/libgd/src/gd.c:1333: undefined reference to `atan2'
>> > /usr/src/libgd/src/gd.c:1333: undefined reference to `cos'
>> > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine':
>> > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2'
>> > /usr/src/libgd/src/gd.c:3514: undefined reference to `sin'
>> > /opt/local/lib/libgd.a(gd.o): In function `gdImageCopyRotated':
>> > /usr/src/libgd/src/gd.c:2792: undefined reference to `sincos'
>> > /usr/src/libgd/src/gd.c:2791: undefined reference to `sqrt'
>> > collect2: error: ld returned 1 exit status
>> > --
>> >
>> > Версия nginx 1.15.10. gcc version 4.8.2.
>> >
>> > сб, 6 апр. 2019 г. в 12:14, Igor Sysoev :
>> > А что в autoconf.err ?
>> >
>> > --
>> > Igor Sysoev
>> > http://nginx.com
>> >
>> > > On 6 Apr 2019, at 14:07, Anton Kiryushkin wrote:
>> > >
>> > > Добавил и не помогло.
>> > >
>> > > сб, 6 апр. 2019 г. в 11:06, Igor Sysoev :
>> > > > On 6 Apr 2019, at 12:54, Anton Kiryushkin
>> wrote:
>> > > >
>> > > > Здравствуйте.
>> > > >
>> > > > Подскажите, пожалуйста, почему nginx в данном случае никак не может
>> собраться статически с
Re: https cpu load
On Sun, Apr 07, 2019 at 11:12:50PM +0500, Илья Шипицин wrote: > > > естественно. я предполагаю, что тот, кто будет сравнивать, понимает это. > > > > и при этом не сообщая ничего о своем (референсном в данном случае) > > профиле нагрузке? оригинально > > > > это некое предположение, что "среднее хорошо написанное веб-приложение для > браузера" работает примерно одинаково. я не заметил, там говорилось что нгинкс колокейтится с приложением? он не статику раздает, не проксей работает? > > > > > > > > > > > > > > > Вообще, я с вами согласен, моё предложение посмотреть профайлер было > > как > > > > > раз про это. > > > > > > > > нет никакого смысла смотреть профайлер в данный момент. > > > > > > > > > > в любом случае, чтобы узнать, на что расходуется cpu, надо смотреть > > > профайлер. какие еще есть варианты ? > > > > очевидно он расходуется на https, это бесполезное знание. > > > > > неочевидно. > например, у нас 70% cpu это компрессия. > > опять же, https это как минимум два вида нагрузки - ассиметричные хендшейки > и симметричное шифрование. сколько каждого из них, весьма интересно. это бесполезное знание, пока мы не узнали что на это расходуется больше ожидаемого. если у нас большая частота новых соединений то будет пик в ассиметричных хендшейках и что дальше? так и должно быть. и смотреть надо на это для начала, а не профайлинг запускать. да и вообще, поинтересоваться что за процессор и все такое. > из интересных моментов, каким-то странным образом при сборке портов > freebsd, мы умудрились скомпилировать openssl с выключенной ассемблерной > оптимизацией. это надо было постараться, да. даже дважды (т.е. что бы для начала системный не устроил) > по профайлеру увидели, что 25% cpu уходит на "big numbers" арифметику > (которая в случае включенной ассемблерной оптимизации умножилась на ноль). > > еще из интересных моментов, был странный опыт с подменой ответа (какой-то > баг чинили), вылилось это в то, что раздача инсталяторов (при обновлении > тимсити) привела к всплеску cpu. увидели это тоже по gperftools это проявлялось тоьлко на https? > сколько раз использовал gperftools, еще не было повода пожалеть. ни разу не использовал и не жалею. предпочитаю pcstat, но тогда когда имеет смысл. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: https cpu load
вс, 7 апр. 2019 г. в 23:00, Slawa Olhovchenkov : > On Sun, Apr 07, 2019 at 10:02:22PM +0500, Илья Шипицин wrote: > > > вс, 7 апр. 2019 г. в 20:51, Slawa Olhovchenkov : > > > > > On Sun, Apr 07, 2019 at 06:14:18PM +0500, Илья Шипицин wrote: > > > > > > > On Sun, Apr 7, 2019, 1:17 AM Slawa Olhovchenkov > wrote: > > > > > > > > > On Sun, Apr 07, 2019 at 12:14:51AM +0500, Илья Шипицин wrote: > > > > > > > > > > > сб, 6 апр. 2019 г. в 23:40, Evgenii Davidov >: > > > > > > > > > > > > > Здравствуйте, > > > > > > > > > > > > > > On Sat, Apr 06, 2019 at 11:11:19PM +0500, Илья Шипицин пишет: > > > > > > > > > > > > > > > 1 установленных соединений или 1 новых соединений в > > > секунду ? > > > > > > > > > > > > > > спасибо, установленных) > > > > > > > > > > > > > > > > > > > > > > > > > 20 установленных на 1 сервер обрабатываем > > > > > > > > > > какая разница сколько их, если скажем они все простаивают? > > > > > > > > > > имеет значение количество передаваемого трафика по этим > соединениям (в > > > > > гигабитах/с) и количество устанавливаемых соединений в секунду > (когда > > > > > считаются вся ассиметричная математика). > > > > > > > > > > > > > Я предполагаю, что на больших объёмах действует закон больших чисел, > и > > > > количество установленных соединений вытекает из того, что вы > написали. > > > > > > прежде чем ссылаться на закон больших чисел надо убедиться что в обоих > > > случаях происодит один и тот же эксперимент. > > > > > > > естественно. я предполагаю, что тот, кто будет сравнивать, понимает это. > > и при этом не сообщая ничего о своем (референсном в данном случае) > профиле нагрузке? оригинально > это некое предположение, что "среднее хорошо написанное веб-приложение для браузера" работает примерно одинаково. > > > > > > > > > > Вообще, я с вами согласен, моё предложение посмотреть профайлер было > как > > > > раз про это. > > > > > > нет никакого смысла смотреть профайлер в данный момент. > > > > > > > в любом случае, чтобы узнать, на что расходуется cpu, надо смотреть > > профайлер. какие еще есть варианты ? > > очевидно он расходуется на https, это бесполезное знание. > неочевидно. например, у нас 70% cpu это компрессия. опять же, https это как минимум два вида нагрузки - ассиметричные хендшейки и симметричное шифрование. сколько каждого из них, весьма интересно. из интересных моментов, каким-то странным образом при сборке портов freebsd, мы умудрились скомпилировать openssl с выключенной ассемблерной оптимизацией. по профайлеру увидели, что 25% cpu уходит на "big numbers" арифметику (которая в случае включенной ассемблерной оптимизации умножилась на ноль). еще из интересных моментов, был странный опыт с подменой ответа (какой-то баг чинили), вылилось это в то, что раздача инсталяторов (при обновлении тимсити) привела к всплеску cpu. увидели это тоже по gperftools сколько раз использовал gperftools, еще не было повода пожалеть. > интересоваться профалингом следует тоьлко если производительность не > соответсвет ожидаемой, а это пока не известно. > > > gperftools хорош для этой задачи. > > не имеет значениею > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: https cpu load
On Sun, Apr 07, 2019 at 10:02:22PM +0500, Илья Шипицин wrote: > вс, 7 апр. 2019 г. в 20:51, Slawa Olhovchenkov : > > > On Sun, Apr 07, 2019 at 06:14:18PM +0500, Илья Шипицин wrote: > > > > > On Sun, Apr 7, 2019, 1:17 AM Slawa Olhovchenkov wrote: > > > > > > > On Sun, Apr 07, 2019 at 12:14:51AM +0500, Илья Шипицин wrote: > > > > > > > > > сб, 6 апр. 2019 г. в 23:40, Evgenii Davidov : > > > > > > > > > > > Здравствуйте, > > > > > > > > > > > > On Sat, Apr 06, 2019 at 11:11:19PM +0500, Илья Шипицин пишет: > > > > > > > > > > > > > 1 установленных соединений или 1 новых соединений в > > секунду ? > > > > > > > > > > > > спасибо, установленных) > > > > > > > > > > > > > > > > > > > > > 20 установленных на 1 сервер обрабатываем > > > > > > > > какая разница сколько их, если скажем они все простаивают? > > > > > > > > имеет значение количество передаваемого трафика по этим соединениям (в > > > > гигабитах/с) и количество устанавливаемых соединений в секунду (когда > > > > считаются вся ассиметричная математика). > > > > > > > > > > Я предполагаю, что на больших объёмах действует закон больших чисел, и > > > количество установленных соединений вытекает из того, что вы написали. > > > > прежде чем ссылаться на закон больших чисел надо убедиться что в обоих > > случаях происодит один и тот же эксперимент. > > > > естественно. я предполагаю, что тот, кто будет сравнивать, понимает это. и при этом не сообщая ничего о своем (референсном в данном случае) профиле нагрузке? оригинально > > > > > > Вообще, я с вами согласен, моё предложение посмотреть профайлер было как > > > раз про это. > > > > нет никакого смысла смотреть профайлер в данный момент. > > > > в любом случае, чтобы узнать, на что расходуется cpu, надо смотреть > профайлер. какие еще есть варианты ? очевидно он расходуется на https, это бесполезное знание. интересоваться профалингом следует тоьлко если производительность не соответсвет ожидаемой, а это пока не известно. > gperftools хорош для этой задачи. не имеет значениею ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Ограничение доступа к папке по IP
Здравствуйте.
Необходимо ограничить доступ к файлам папки /orders-files (в ней содержатся
файлы с расширением doc) по ip, делаю так:
location ^~ /orders-files/ {
allow 123.45.678.90;
deny all;
client_max_body_size 32M;
access_log off;
break;
}
location ~*
^.+\.(css|js|svg|jpg|jpeg|gif|png|ico|zip|rar|doc|xls|pdf|exe|wav|bmp|rtf)$
{
client_max_body_size 128M;
access_log off;
expires 7d;
break;
}
Такое впечатление, что нижний location мешает. Не могли бы помочь
разобраться...
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,283658,283658#msg-283658
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: https cpu load
вс, 7 апр. 2019 г. в 20:51, Slawa Olhovchenkov : > On Sun, Apr 07, 2019 at 06:14:18PM +0500, Илья Шипицин wrote: > > > On Sun, Apr 7, 2019, 1:17 AM Slawa Olhovchenkov wrote: > > > > > On Sun, Apr 07, 2019 at 12:14:51AM +0500, Илья Шипицин wrote: > > > > > > > сб, 6 апр. 2019 г. в 23:40, Evgenii Davidov : > > > > > > > > > Здравствуйте, > > > > > > > > > > On Sat, Apr 06, 2019 at 11:11:19PM +0500, Илья Шипицин пишет: > > > > > > > > > > > 1 установленных соединений или 1 новых соединений в > секунду ? > > > > > > > > > > спасибо, установленных) > > > > > > > > > > > > > > > > > 20 установленных на 1 сервер обрабатываем > > > > > > какая разница сколько их, если скажем они все простаивают? > > > > > > имеет значение количество передаваемого трафика по этим соединениям (в > > > гигабитах/с) и количество устанавливаемых соединений в секунду (когда > > > считаются вся ассиметричная математика). > > > > > > > Я предполагаю, что на больших объёмах действует закон больших чисел, и > > количество установленных соединений вытекает из того, что вы написали. > > прежде чем ссылаться на закон больших чисел надо убедиться что в обоих > случаях происодит один и тот же эксперимент. > естественно. я предполагаю, что тот, кто будет сравнивать, понимает это. > > > Вообще, я с вами согласен, моё предложение посмотреть профайлер было как > > раз про это. > > нет никакого смысла смотреть профайлер в данный момент. > в любом случае, чтобы узнать, на что расходуется cpu, надо смотреть профайлер. какие еще есть варианты ? gperftools хорош для этой задачи. > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: https cpu load
On Sun, Apr 07, 2019 at 06:14:18PM +0500, Илья Шипицин wrote: > On Sun, Apr 7, 2019, 1:17 AM Slawa Olhovchenkov wrote: > > > On Sun, Apr 07, 2019 at 12:14:51AM +0500, Илья Шипицин wrote: > > > > > сб, 6 апр. 2019 г. в 23:40, Evgenii Davidov : > > > > > > > Здравствуйте, > > > > > > > > On Sat, Apr 06, 2019 at 11:11:19PM +0500, Илья Шипицин пишет: > > > > > > > > > 1 установленных соединений или 1 новых соединений в секунду ? > > > > > > > > спасибо, установленных) > > > > > > > > > > > > > 20 установленных на 1 сервер обрабатываем > > > > какая разница сколько их, если скажем они все простаивают? > > > > имеет значение количество передаваемого трафика по этим соединениям (в > > гигабитах/с) и количество устанавливаемых соединений в секунду (когда > > считаются вся ассиметричная математика). > > > > Я предполагаю, что на больших объёмах действует закон больших чисел, и > количество установленных соединений вытекает из того, что вы написали. прежде чем ссылаться на закон больших чисел надо убедиться что в обоих случаях происодит один и тот же эксперимент. > Вообще, я с вами согласен, моё предложение посмотреть профайлер было как > раз про это. нет никакого смысла смотреть профайлер в данный момент. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: https cpu load
07.04.2019, 16:14, "Илья Шипицин" : > On Sun, Apr 7, 2019, 1:17 AM Slawa Olhovchenkov wrote: >> On Sun, Apr 07, 2019 at 12:14:51AM +0500, Илья Шипицин wrote: >> >>> сб, 6 апр. 2019 г. в 23:40, Evgenii Davidov : >>> >>> > Здравствуйте, >>> > >>> > On Sat, Apr 06, 2019 at 11:11:19PM +0500, Илья Шипицин пишет: >>> > >>> > > 1 установленных соединений или 1 новых соединений в секунду ? >>> > >>> > спасибо, установленных) >>> > >>> >>> >>> 20 установленных на 1 сервер обрабатываем >> >> какая разница сколько их, если скажем они все простаивают? >> >> имеет значение количество передаваемого трафика по этим соединениям (в >> гигабитах/с) и количество устанавливаемых соединений в секунду (когда >> считаются вся ассиметричная математика). > > Я предполагаю, что на больших объёмах действует закон больших чисел, и > количество установленных соединений вытекает из того, что вы написали. При разном характере нагрузки среднее время жизни соединения может быть очень разным -- Regards, Konstantin ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Количество клиенстких ошибок выросло после обновления до новой nginx(1.14.2) c новым openssl (1.0.2g)
On Sun, Apr 7, 2019, 5:45 PM Dmitry Sergeev wrote: > Количество ошибок на уровне HTTP - может быть нерелевантно > происходящему, и, скажем, означать, что больше проблемных клиентов > теперь могут пройти через SSL handshake. > > Ну и смотреть надо не на абсолютные цифры, а на проценты от > трафика. Если речь про доли процента - наблюдаемое изменение > может быть следствием того, что проблемы возникают у каких-либо > малораспространённых клинтов, и совершенно не факт, что на это > надо обращать внимание. Например, из OpenSSL 1.0.2 могли убрать > какие-то workaround'ы для ошибочного поведения, или же из-за > изменения списка шифров теперь используются другие шифры, которые, > наоборот, вызывают проблемы в этих клиентах. > > Ну не знаю, количество ошибок, которое возросло в 3-4 раза, как по мне > стоит того, чтобы обратить внимание. Доля трафика конечно небольшая, я > думаю примерно в пределах одного процента, а точнее: 0.24% запросов это > ошибки (499,408,400). Но обычно эта доля составляет 0.05%, что и > А каких-нибудь мобильных клиентов на okhttp старых версий (у них очень плохо с http2) нет? расстраивает. Надо конечно это считать не по количеству запросов, а по > количеству пользователей, которых это затрагивает, но все же. > > Если же хочется таки разобраться - то имеет смысл смотреть > подробную информацию по ошибкам, в частности - что при этом пишет > nginx в логи (если есть подробности - они скорее всего на уровне > info), и что известно про этих клиентов - User-Agent, используемые > протоколы, шифры и так далее. > > Да, спасибо. Буду исследовать дальше. > > В первую очередь - в OpenSSL 1.0.1 нет ALPN, то есть HTTP/2 в > современных браузерах работать не будет. Если в конфиге включён > HTTP/2 - переход на OpenSSL 1.0.2 будет сильным изменением > поведения в любом случае. Так что имеет смысл HTTP/2 выключить и > сравнивать строго без HTTP/2. Важно при этом выключить везде, > потому как http2 - это опция сокета, и если она останется в любом > из блоков server, то HTTP/2 продолжит работать. > > Тестил как с http2 так и без него, результат один и тот же. Про то что > отключать его нужно во всех блоках server знаю, после выключения > непосредственно проверял вручную, выключился ли он действительно. > > Если вдруг используются множественные сертификаты в одном блоке > server - переход с OpenSSL 1.0.1 на 1.0.2 потребует изменения > цепочек в ssl_certificate, т.к. в случае OpenSSL 1.0.1 цепочка > только одна и общаяя для всех сертификатов, а в случае 1.0.2 - у > каждого сертификата своя. > > Я к сожалению не очень разбираюсь в этом, я использую wildcard сертификаты > от letsencrypt. То что сгенирировал certbot то и даю nginx. Как писал > раннее, тестил версии openssl: 1.0.1u, 1.0.2g, 1.1.1b. Данная проблема > воспроизводится успешно на 1.0.2g и 1.1.1b. > > Спасибо за наводки, понял, что проблема скорее всего на клиентской стороне > с поддержкой алгоритмов ssl или еще какие-то, буду исследовать дальше. > > > -- > > Kind regards > Dmitry Sergeev > Tel: +7 (951) 129-75-72 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: https cpu load
On Sun, Apr 7, 2019, 1:17 AM Slawa Olhovchenkov wrote: > On Sun, Apr 07, 2019 at 12:14:51AM +0500, Илья Шипицин wrote: > > > сб, 6 апр. 2019 г. в 23:40, Evgenii Davidov : > > > > > Здравствуйте, > > > > > > On Sat, Apr 06, 2019 at 11:11:19PM +0500, Илья Шипицин пишет: > > > > > > > 1 установленных соединений или 1 новых соединений в секунду ? > > > > > > спасибо, установленных) > > > > > > > > > 20 установленных на 1 сервер обрабатываем > > какая разница сколько их, если скажем они все простаивают? > > имеет значение количество передаваемого трафика по этим соединениям (в > гигабитах/с) и количество устанавливаемых соединений в секунду (когда > считаются вся ассиметричная математика). > Я предполагаю, что на больших объёмах действует закон больших чисел, и количество установленных соединений вытекает из того, что вы написали. Вообще, я с вами согласен, моё предложение посмотреть профайлер было как раз про это. ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Количество клиенстких ошибок выросло после обновления до новой nginx(1.14.2) c новым openssl (1.0.2g)
Количество ошибок на уровне HTTP - может быть нерелевантно происходящему, и, скажем, означать, что больше проблемных клиентов теперь могут пройти через SSL handshake. Ну и смотреть надо не на абсолютные цифры, а на проценты от трафика. Если речь про доли процента - наблюдаемое изменение может быть следствием того, что проблемы возникают у каких-либо малораспространённых клинтов, и совершенно не факт, что на это надо обращать внимание. Например, из OpenSSL 1.0.2 могли убрать какие-то workaround'ы для ошибочного поведения, или же из-за изменения списка шифров теперь используются другие шифры, которые, наоборот, вызывают проблемы в этих клиентах. Ну не знаю, количество ошибок, которое возросло в 3-4 раза, как по мне стоит того, чтобы обратить внимание. Доля трафика конечно небольшая, я думаю примерно в пределах одного процента, а точнее: 0.24% запросов это ошибки (499,408,400). Но обычно эта доля составляет 0.05%, что и расстраивает. Надо конечно это считать не по количеству запросов, а по количеству пользователей, которых это затрагивает, но все же. Если же хочется таки разобраться - то имеет смысл смотреть подробную информацию по ошибкам, в частности - что при этом пишет nginx в логи (если есть подробности - они скорее всего на уровне info), и что известно про этих клиентов - User-Agent, используемые протоколы, шифры и так далее. Да, спасибо. Буду исследовать дальше. В первую очередь - в OpenSSL 1.0.1 нет ALPN, то есть HTTP/2 в современных браузерах работать не будет. Если в конфиге включён HTTP/2 - переход на OpenSSL 1.0.2 будет сильным изменением поведения в любом случае. Так что имеет смысл HTTP/2 выключить и сравнивать строго без HTTP/2. Важно при этом выключить везде, потому как http2 - это опция сокета, и если она останется в любом из блоков server, то HTTP/2 продолжит работать. Тестил как с http2 так и без него, результат один и тот же. Про то что отключать его нужно во всех блоках server знаю, после выключения непосредственно проверял вручную, выключился ли он действительно. Если вдруг используются множественные сертификаты в одном блоке server - переход с OpenSSL 1.0.1 на 1.0.2 потребует изменения цепочек в ssl_certificate, т.к. в случае OpenSSL 1.0.1 цепочка только одна и общаяя для всех сертификатов, а в случае 1.0.2 - у каждого сертификата своя. Я к сожалению не очень разбираюсь в этом, я использую wildcard сертификаты от letsencrypt. То что сгенирировал certbot то и даю nginx. Как писал раннее, тестил версии openssl: 1.0.1u, 1.0.2g, 1.1.1b. Данная проблема воспроизводится успешно на 1.0.2g и 1.1.1b. Спасибо за наводки, понял, что проблема скорее всего на клиентской стороне с поддержкой алгоритмов ssl или еще какие-то, буду исследовать дальше. -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Статическая сборка nginx с GD
Да, конечно, есть: # find /usr -type f -name 'libm.a' /usr/lib/x86_64-linux-gnu/libm.a Да, я попробовал поставить -lm перед -static, это мне тоже не помогло. К слову, libgd тоже там есть: # find /usr -type f -name 'libgd.a' /usr/lib/x86_64-linux-gnu/libgd.a Подскажите, пожалуйста, где эти тесты лежат в исходнике, поправлю локально, как обычно это делаю с php. сб, 6 апр. 2019 г. в 19:22, Igor Sysoev : > А статическая libm.a есть? > Можно попробовать поставить -lm до -static: > > --with-ld-opt="-lm -static ... > > -- > Igor Sysoev > http://nginx.com > > > On 6 Apr 2019, at 14:57, Anton Kiryushkin wrote: > > > > Ситуация очень напоминает предыдущую: > > > > cc -static -static-libgcc -lm -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I > /usr/pkg/include -o objs/autotest objs/autotest.c -static -lm > -L/usr/pkg/lib -lgd > > -- > > > > > > checking for GD library in /opt/local/ > > > > /opt/local/lib/libgd.a(gd.o): In function `lsqrt': > > /usr/src/libgd/src/gd.c:1722: undefined reference to `sqrt' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageDashedLine': > > /usr/src/libgd/src/gd.c:1471: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1471: undefined reference to `sin' > > /usr/src/libgd/src/gd.c:1520: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1520: undefined reference to `sin' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:3514: undefined reference to `cos' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageLine': > > /usr/src/libgd/src/gd.c:1394: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1394: undefined reference to `sin' > > /usr/src/libgd/src/gd.c:1333: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1333: undefined reference to `cos' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:3514: undefined reference to `sin' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageCopyRotated': > > /usr/src/libgd/src/gd.c:2792: undefined reference to `sincos' > > /usr/src/libgd/src/gd.c:2791: undefined reference to `sqrt' > > collect2: error: ld returned 1 exit status > > -- > > > > Версия nginx 1.15.10. gcc version 4.8.2. > > > > сб, 6 апр. 2019 г. в 12:14, Igor Sysoev : > > А что в autoconf.err ? > > > > -- > > Igor Sysoev > > http://nginx.com > > > > > On 6 Apr 2019, at 14:07, Anton Kiryushkin wrote: > > > > > > Добавил и не помогло. > > > > > > сб, 6 апр. 2019 г. в 11:06, Igor Sysoev : > > > > On 6 Apr 2019, at 12:54, Anton Kiryushkin wrote: > > > > > > > > Здравствуйте. > > > > > > > > Подскажите, пожалуйста, почему nginx в данном случае никак не может > собраться статически с libgd: > > > > > > > > -- > > > > cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I > /usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib > -lgd > > > > -- > > > > > > > > > > > > checking for GD library in /opt/local/ > > > > > > > > /opt/local/lib/libgd.a(gd.o): In function `lsqrt': > > > > /usr/src/libgd/src/gd.c:1722: undefined reference to `sqrt' > > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageDashedLine': > > > > /usr/src/libgd/src/gd.c:1471: undefined reference to `atan2' > > > > /usr/src/libgd/src/gd.c:1471: undefined reference to `sin' > > > > /usr/src/libgd/src/gd.c:1520: undefined reference to `atan2' > > > > /usr/src/libgd/src/gd.c:1520: undefined reference to `sin' > > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `cos' > > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageLine': > > > > /usr/src/libgd/src/gd.c:1394: undefined reference to `atan2' > > > > /usr/src/libgd/src/gd.c:1394: undefined reference to `sin' > > > > /usr/src/libgd/src/gd.c:1333: undefined reference to `atan2' > > > > /usr/src/libgd/src/gd.c:1333: undefined reference to `cos' > > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `sin' > > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageCopyRotated': > > > > /usr/src/libgd/src/gd.c:2792: undefined reference to `sincos' > > > > /usr/src/libgd/src/gd.c:2791: undefined reference to `sqrt' > > > > collect2: error: ld returned 1 exit status > > > > -- > > > > > > > > Сам libgd собран в /opt/local с флагом static. К сожалению, мне > действительно нужна статическая сборка. Остается страдать и все же так не > делать или есть способ что-то тут сделать? > > > > > > Нужно добавить "-lm" в --with-ld-opt > > > > > > > > > -- > > > Igor Sysoev > > > http://nginx.com > > >
