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 > > >