Re: nginx полностью загружает весь процессор при reload'e
Hello! On Tue, Sep 03, 2019 at 03:18:36PM +0500, Dmitry Sergeev wrote: > Добрый день, спасибо за ответ. > > On 02/09/2019 22:11, Maxim Dounin wrote: > > Just in case, для работы такая конфигурация смысла не имеет - если > > тикеты выключены, то ключ для их шифрования не нужен. Ключ имеет > > смысл задавать, если тикеты включены. > > > > С точки зрения влияния на reload - внешний ключ позволит сохранить > > тикеты при reload'ах, а выключение тикетов - уведёт всё в кэш > > сессий. > > > > Ну выключать тикеты - это, безусловно, плохой путь. Тикеты - > > способ переложить хранение сессий на клиентов, и отказываться от > > этого - очевидно недальновидно с точки зрения нагрузки на сервер. > > > Да, я неверно понял доки. > > > Отмечу также, что даже в наиболее экстремальных случаях из > > представленных на графике - рост потребления процессора с ~200% до > > ~300% не выглядит сколько-нибудь фатальным. Какой-то рост > > потребления процессора при релоадах - нормален, здесь же > > наблюдается рост всего в 1.5 раза. Если это проблема - то стоит > > задуматься о добавлении мощностей и/или заняться оптимизацией > Да, сейчас это для меня просто представляет интерес, после перехода на > openssl 1.0.2g и включение http2, проблем это особых не вызывает. > > А вот то, что средняя нагрузка без тикетов заметно выше - это > > немного странно. Само хранение сессий - должно бы стоить очень > > недорого с точки зрения процессора, а в остальном разница не > > принципиальна. Но, возможно, тут дело в том, что размер кэша > > SSL-сессий просто мал для имеющегося количества клиентов, и > > поэтому при выключении тикетов handshake'и начинают происходить > > чаще, что и приводит к росту потребления процессора. > Возможно. Это немного не то, но мне было интересно как увеличение кэша > ssl сессий повлияет на нагрузку при reload'e: > > http://dl4.joxi.net/drive/2019/09/03/0030/2608/1985072/72/8608b87db7.jpg > > Числами отметил разное количество ssl_session_cache от 20m до 256m. > Вроде никак не влияет. Сегодня тестил при 8K rps (вчера 5-6K). Поэтому > нагрузка скачет чуть выше. От размера кэша сессий должна зависеть высота "полки" между reload'ами. Если кэш мал - то полных handshake'ов будет больше, чем могло бы быть, и соответственно CPU usage в полке будет больше. Ну и всё это имеет смысл скорее при выключенных тикетах, о чём и шла речь выше. А на графике - они, похоже, включены. > А вот тикеты помогли вообще круто. Нагрузка поднимается всего-лишь на > 5%-10%: > http://dl3.joxi.net/drive/2019/09/03/0030/2608/1985072/72/ac00a4d2d0.jpg > > Здесь 1 - это без ssl_session_ticket_key, а 2,3,4 - c включенными > тикетами и указанными постояным ключем ssl_session_ticket_key. Ну ок, то есть как и ожидалось - пик явно из-за SSL handshake'ов, использование постоянных ключей для тикетов - лечит. > Итого: > > Сущесвтенно решить проблему помогло следующее: > 1) переход на http2 (openssl 1.02.g) - понизилась нагрузка в целом, и > при reload'e нагрузка конечно возрастала, но не надолго (5-20 секунд, а > раньше от 30-40 секунд, до 5 минут). > 2) И вообще убрать хоть какое-то сущесвтенное повышение нагрзуки помогло > включение ssl_session_tickets(по умолчанию включено) с установелнным > ssl_session_ticket_key (по умолчанию генерируется заново при каждом > reload'e, его лучше указать чтобы этого не происходило). > > Оставил такие параметры: > > ssl_session_cache shared:SSL:20m; > ssl_session_timeout 30m; > ssl_session_tickets on; > ssl_session_ticket_key /etc/nginx/ssl/ticket.key; # ticket.key - > файл с рандомными 80 или 48 байт > > Кэш ssl сессий оставил, хоть в моем случае он вроде как сильно не влияет > (по крайней мере я этого не заметил). Использовать "ssl_session_tickets on;" - не нужно, это поведение по умолчанию. И отмечу также, что ключ для тикетов - надо периодически менять, ибо получив этот ключ - можно расшифровать весь трафик. И я бы ещё рекомендовал посмотреть в сторону ECDSA-сертификатов, там handshake банально на порядок быстрее при той же криптостойкости: $ openssl speed rsa2048 ecdsap256 ... signverifysign/s verify/s rsa 2048 bits 0.000992s 0.33s 1008.1 30297.9 signverifysign/s verify/s 256 bit ecdsa (nistp256) 0.0001s 0.0001s 17145.0 9276.9 То есть 1008.1 подписей в секунду в случае RSA 2048 bit, и 17145.0 подписей в секунду для ECDSA 256 bit. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx полностью загружает весь процессор при reload'e
Добрый день, спасибо за ответ. On 02/09/2019 22:11, Maxim Dounin wrote: Just in case, для работы такая конфигурация смысла не имеет - если тикеты выключены, то ключ для их шифрования не нужен. Ключ имеет смысл задавать, если тикеты включены. С точки зрения влияния на reload - внешний ключ позволит сохранить тикеты при reload'ах, а выключение тикетов - уведёт всё в кэш сессий. Ну выключать тикеты - это, безусловно, плохой путь. Тикеты - способ переложить хранение сессий на клиентов, и отказываться от этого - очевидно недальновидно с точки зрения нагрузки на сервер. Да, я неверно понял доки. Отмечу также, что даже в наиболее экстремальных случаях из представленных на графике - рост потребления процессора с ~200% до ~300% не выглядит сколько-нибудь фатальным. Какой-то рост потребления процессора при релоадах - нормален, здесь же наблюдается рост всего в 1.5 раза. Если это проблема - то стоит задуматься о добавлении мощностей и/или заняться оптимизацией Да, сейчас это для меня просто представляет интерес, после перехода на openssl 1.0.2g и включение http2, проблем это особых не вызывает. А вот то, что средняя нагрузка без тикетов заметно выше - это немного странно. Само хранение сессий - должно бы стоить очень недорого с точки зрения процессора, а в остальном разница не принципиальна. Но, возможно, тут дело в том, что размер кэша SSL-сессий просто мал для имеющегося количества клиентов, и поэтому при выключении тикетов handshake'и начинают происходить чаще, что и приводит к росту потребления процессора. Возможно. Это немного не то, но мне было интересно как увеличение кэша ssl сессий повлияет на нагрузку при reload'e: http://dl4.joxi.net/drive/2019/09/03/0030/2608/1985072/72/8608b87db7.jpg Числами отметил разное количество ssl_session_cache от 20m до 256m. Вроде никак не влияет. Сегодня тестил при 8K rps (вчера 5-6K). Поэтому нагрузка скачет чуть выше. А вот тикеты помогли вообще круто. Нагрузка поднимается всего-лишь на 5%-10%: http://dl3.joxi.net/drive/2019/09/03/0030/2608/1985072/72/ac00a4d2d0.jpg Здесь 1 - это без ssl_session_ticket_key, а 2,3,4 - c включенными тикетами и указанными постояным ключем ssl_session_ticket_key. Итого: Сущесвтенно решить проблему помогло следующее: 1) переход на http2 (openssl 1.02.g) - понизилась нагрузка в целом, и при reload'e нагрузка конечно возрастала, но не надолго (5-20 секунд, а раньше от 30-40 секунд, до 5 минут). 2) И вообще убрать хоть какое-то сущесвтенное повышение нагрзуки помогло включение ssl_session_tickets(по умолчанию включено) с установелнным ssl_session_ticket_key (по умолчанию генерируется заново при каждом reload'e, его лучше указать чтобы этого не происходило). Оставил такие параметры: ssl_session_cache shared:SSL:20m; ssl_session_timeout 30m; ssl_session_tickets on; ssl_session_ticket_key /etc/nginx/ssl/ticket.key; # ticket.key - файл с рандомными 80 или 48 байт Кэш 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 полностью загружает весь процессор при reload'e
Hello! On Mon, Sep 02, 2019 at 08:54:51PM +0500, Dmitry Sergeev wrote: > Спасибо большое за ответ. > > Потестил с параметрами: > > ssl_session_tickets off; > ssl_session_ticket_key /etc/nginx/ssl/ticket.key; Just in case, для работы такая конфигурация смысла не имеет - если тикеты выключены, то ключ для их шифрования не нужен. Ключ имеет смысл задавать, если тикеты включены. С точки зрения влияния на reload - внешний ключ позволит сохранить тикеты при reload'ах, а выключение тикетов - уведёт всё в кэш сессий. > И довольно интересно получилось: > http://joxi.net/krD6q0jTKkV9R2.jpg > > На картинке числами отмечены reload'ы > 1,2,6,7,10 - без настроек tickets (по умоланию включен) > 3,4,5,8,9 - с отключенным tickets и файлом ssl_session_ticket_key. > > При этом всегда был включен кэш сессий: > > ssl_session_cache shared:SSL:20m; > ssl_session_timeout 30m; > > Пока сделал вывод, что с отключенным ssl_session_tickets средняя > нагрузка выше, но при этом при reload'e нагрузка не так сильно > возрастает по отношению к средней. Тесты не совсем чистые, постараюсь > сделать более чистый эксперимент. Ну выключать тикеты - это, безусловно, плохой путь. Тикеты - способ переложить хранение сессий на клиентов, и отказываться от этого - очевидно недальновидно с точки зрения нагрузки на сервер. А вот то, что средняя нагрузка без тикетов заметно выше - это немного странно. Само хранение сессий - должно бы стоить очень недорого с точки зрения процессора, а в остальном разница не принципиальна. Но, возможно, тут дело в том, что размер кэша SSL-сессий просто мал для имеющегося количества клиентов, и поэтому при выключении тикетов handshake'и начинают происходить чаще, что и приводит к росту потребления процессора. Отмечу также, что даже в наиболее экстремальных случаях из представленных на графике - рост потребления процессора с ~200% до ~300% не выглядит сколько-нибудь фатальным. Какой-то рост потребления процессора при релоадах - нормален, здесь же наблюдается рост всего в 1.5 раза. Если это проблема - то стоит задуматься о добавлении мощностей и/или заняться оптимизацией. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx полностью загружает весь процессор при reload'e
Спасибо большое за ответ. Потестил с параметрами: ssl_session_tickets off; ssl_session_ticket_key /etc/nginx/ssl/ticket.key; И довольно интересно получилось: http://joxi.net/krD6q0jTKkV9R2.jpg На картинке числами отмечены reload'ы 1,2,6,7,10 - без настроек tickets (по умоланию включен) 3,4,5,8,9 - с отключенным tickets и файлом ssl_session_ticket_key. При этом всегда был включен кэш сессий: ssl_session_cache shared:SSL:20m; ssl_session_timeout 30m; Пока сделал вывод, что с отключенным ssl_session_tickets средняя нагрузка выше, но при этом при reload'e нагрузка не так сильно возрастает по отношению к средней. Тесты не совсем чистые, постараюсь сделать более чистый эксперимент. On 02/09/2019 16:55, Maxim Dounin wrote: Hello! On Sat, Aug 31, 2019 at 12:54:06PM +0500, Dmitry Sergeev wrote: Добрый день! Спасибо за ответ. Конфиг полный, просто сократил количетсво виртуальных хостов, так как они одинаковые. В конфиге значилось: include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; Так что понять по нему, полный он, или нет - не представляется возможным, отсюда и вопросы. ssl_session_cache - действительно не настроено. ssl_dhparam - аналогично. сертификат один общий для всех, сгенерировал его для wildcard домена от let's encrypt (Signature Algorithm: sha256WithRSAEncryption, Public-Key: rsaEncryption (2048 bit)). Пытался оптимизировать ssl и посмотреть влияние его настроек на эту проблему. В частности пробовал глобально добавлять опции: *ssl_session_cache shared:SSL:20m;* *ssl_session_timeout 30m; *вроде никак не влияло, но я проверю еще раз конечно, и более чательно. Если большая часть клиентов использует тикеты - то может и не повлиять. Для теста можно попробовать отключить тикеты (ssl_session_tickets) и/или настроить внешний ключ (ssl_session_ticket_key), так как автоматически сгенерированные ключи при reload'е обновляются. Про ssl_dhparam не понял, с точки зрения производительности - его лучше добавлять но с небольшой битностью (2048 и меньше) или лучше совсем не использовать? Лучше - не использовать. Даже 2048 для классического Диффи-Хеллмана - это очень медленно. -- 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 полностью загружает весь процессор при reload'e
Hello! On Sat, Aug 31, 2019 at 12:54:06PM +0500, Dmitry Sergeev wrote: > Добрый день! > Спасибо за ответ. > > Конфиг полный, просто сократил количетсво виртуальных хостов, так как они > одинаковые. В конфиге значилось: include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; Так что понять по нему, полный он, или нет - не представляется возможным, отсюда и вопросы. > ssl_session_cache - действительно не настроено. > ssl_dhparam - аналогично. > сертификат один общий для всех, сгенерировал его для wildcard домена от let's > encrypt (Signature Algorithm: sha256WithRSAEncryption, Public-Key: > rsaEncryption (2048 bit)). > > Пытался оптимизировать ssl и посмотреть влияние его настроек на эту проблему. > В частности пробовал глобально добавлять опции: > > *ssl_session_cache shared:SSL:20m;* > *ssl_session_timeout 30m; *вроде никак не влияло, но я проверю еще раз > конечно, и более чательно. Если большая часть клиентов использует тикеты - то может и не повлиять. Для теста можно попробовать отключить тикеты (ssl_session_tickets) и/или настроить внешний ключ (ssl_session_ticket_key), так как автоматически сгенерированные ключи при reload'е обновляются. > Про ssl_dhparam не понял, с точки зрения производительности - > его лучше добавлять но с небольшой битностью (2048 и меньше) или > лучше совсем не использовать? Лучше - не использовать. Даже 2048 для классического Диффи-Хеллмана - это очень медленно. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx полностью загружает весь процессор при reload'e
Добрый день! Спасибо за ответ. Конфиг полный, просто сократил количетсво виртуальных хостов, так как они одинаковые. ssl_session_cache - действительно не настроено. ssl_dhparam - аналогично. сертификат один общий для всех, сгенерировал его для wildcard домена от let's encrypt (Signature Algorithm: sha256WithRSAEncryption, Public-Key: rsaEncryption (2048 bit)). Пытался оптимизировать ssl и посмотреть влияние его настроек на эту проблему. В частности пробовал глобально добавлять опции: *ssl_session_cache shared:SSL:20m;* *ssl_session_timeout 30m; *вроде никак не влияло, но я проверю еще раз конечно, и более чательно. Про ssl_dhparam не понял, с точки зрения производительности - его лучше добавлять но с небольшой битностью (2048 и меньше) или лучше совсем не использовать? Большое спасибо за советы. ** On 30/08/2019 17:49, Maxim Dounin wrote: Hello! On Wed, Aug 28, 2019 at 09:18:44PM +0500, Dmitry Sergeev wrote: Вообще мне это конечно помогло, но не полностью. На версии 1.0.2g во время reload'а проц грузит полностью около 5-10 секунд (вместо 40-300 секунд на 1.0.1u), теперь просто оно особо проблем не вызывает у клиентов. Но в целом проблема осталась, просто теперь она не так сильно беспокоит. Сейчас задача замедлилась, но в итоге буду поднимать тестовый стенд с нагрузкой, и смотреть можно ли как-то повлиять на это. Если конечно тут не подскажут, что еще можно подкрутить. Судя по perf top, проблема в том, что клиенты после reload'а переустанавливают соединения, и это выливается в полный SSL handshake - что и приводит к потреблению CPU. Посмотреть стоит на: - ssl_session_cache - в конфиге его, судя по всему, нет (или соответствующие части конфига не показаны); - сертификаты, в частности - их битность (just in case, RSA более 2048 использовать не надо, это тупо очень дорого с точки зрения процессора) и тип (лучше использовать ECDSA, но тут уже может встать вопрос совместимости; при желании можно использовать и RSA и ECDSA одновременно); - используемые шифры, особенно - шифры с классическим DH для обмена ключами (по умолчанию эти шифры не используются начиная с nginx 1.11.0, но некоторые любят указывать ssl_dhparam в конфиге, да ещё и с параметрами большой битности; не надо так); Насчет старых клиентов, точно не могу сказать, но есть такой кейс http://mailman.nginx.org/pipermail/nginx-ru/2019-April/062014.html. Я хорошо не изучал этот вопрос, но факт остается, на старой версии openssl ошибок у клиентов в 3-4 раза было меньше. В итоге решили что это клиенты с очень старым ssl. Как уже говорилось в треде по ссылке, использование OpenSSL 1.0.1u автоматически означет, что HTTP/2 с большинством клиентов работать не будет. С учётом "listen ... http2" в конфиге - обновление до 1.0.2 могло "помочь" просто за счёт того, что HTTP/2 заработал, и количество устанавливаемых соединений соответственно уменьшилось. -- 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 полностью загружает весь процессор при reload'e
Hello! On Wed, Aug 28, 2019 at 09:18:44PM +0500, Dmitry Sergeev wrote: > Вообще мне это конечно помогло, но не полностью. На версии 1.0.2g во > время reload'а проц грузит полностью около 5-10 секунд (вместо 40-300 > секунд на 1.0.1u), теперь просто оно особо проблем не вызывает у > клиентов. Но в целом проблема осталась, просто теперь она не так сильно > беспокоит. > > Сейчас задача замедлилась, но в итоге буду поднимать тестовый стенд с > нагрузкой, и смотреть можно ли как-то повлиять на это. > Если конечно тут не подскажут, что еще можно подкрутить. Судя по perf top, проблема в том, что клиенты после reload'а переустанавливают соединения, и это выливается в полный SSL handshake - что и приводит к потреблению CPU. Посмотреть стоит на: - ssl_session_cache - в конфиге его, судя по всему, нет (или соответствующие части конфига не показаны); - сертификаты, в частности - их битность (just in case, RSA более 2048 использовать не надо, это тупо очень дорого с точки зрения процессора) и тип (лучше использовать ECDSA, но тут уже может встать вопрос совместимости; при желании можно использовать и RSA и ECDSA одновременно); - используемые шифры, особенно - шифры с классическим DH для обмена ключами (по умолчанию эти шифры не используются начиная с nginx 1.11.0, но некоторые любят указывать ssl_dhparam в конфиге, да ещё и с параметрами большой битности; не надо так); > Насчет старых клиентов, точно не могу сказать, но есть такой кейс > http://mailman.nginx.org/pipermail/nginx-ru/2019-April/062014.html. Я > хорошо не изучал этот вопрос, но факт остается, на старой версии openssl > ошибок у клиентов в 3-4 раза было меньше. В итоге решили что это клиенты > с очень старым ssl. Как уже говорилось в треде по ссылке, использование OpenSSL 1.0.1u автоматически означет, что HTTP/2 с большинством клиентов работать не будет. С учётом "listen ... http2" в конфиге - обновление до 1.0.2 могло "помочь" просто за счёт того, что HTTP/2 заработал, и количество устанавливаемых соединений соответственно уменьшилось. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx полностью загружает весь процессор при reload'e
А ради интереса, можете для истории снять SSL labs server test для двух ваших версий openssl? У него есть табличка с эмуляцией хендшейков, будут в ней отличия или нет? On Wed, Aug 28, 2019, 9:19 PM Dmitry Sergeev wrote: > Вообще мне это конечно помогло, но не полностью. На версии 1.0.2g во > время reload'а проц грузит полностью около 5-10 секунд (вместо 40-300 > секунд на 1.0.1u), теперь просто оно особо проблем не вызывает у > клиентов. Но в целом проблема осталась, просто теперь она не так сильно > беспокоит. > > Сейчас задача замедлилась, но в итоге буду поднимать тестовый стенд с > нагрузкой, и смотреть можно ли как-то повлиять на это. > Если конечно тут не подскажут, что еще можно подкрутить. > > Насчет старых клиентов, точно не могу сказать, но есть такой кейс > http://mailman.nginx.org/pipermail/nginx-ru/2019-April/062014.html. Я > хорошо не изучал этот вопрос, но факт остается, на старой версии openssl > ошибок у клиентов в 3-4 раза было меньше. В итоге решили что это клиенты > с очень старым ssl. > > On 27/08/2019 23:25, ngnx8810773a83 wrote: > > А с какими старыми клиентами не совместим 1.0.2g, который сам тоже не > > слишком свеж ? В мае был релиз 1.0.2s а g, это гдето в марте 16 года > было. > > > > Если Вы про sslv2 то оно там есть.у меня специально для этих целей живет > > нгинкс собранный с 1.0.2m. > > если кастомный openssl собиратете через сборку nginx с --with-openssl , > то > > ему можно пихнуть кастомные параметры в configure через > --with-openssl-opt > > для всяких оптимизаций. если совсем какито раритеты, то пихните туда > > enable-weak-ssl-ciphers enable-ssl2.. > > > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,285412,285421#msg-285421 > > > > ___ > > nginx-ru mailing list > > nginx-ru@nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > -- > 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: nginx полностью загружает весь процессор при reload'e
Вообще мне это конечно помогло, но не полностью. На версии 1.0.2g во время reload'а проц грузит полностью около 5-10 секунд (вместо 40-300 секунд на 1.0.1u), теперь просто оно особо проблем не вызывает у клиентов. Но в целом проблема осталась, просто теперь она не так сильно беспокоит. Сейчас задача замедлилась, но в итоге буду поднимать тестовый стенд с нагрузкой, и смотреть можно ли как-то повлиять на это. Если конечно тут не подскажут, что еще можно подкрутить. Насчет старых клиентов, точно не могу сказать, но есть такой кейс http://mailman.nginx.org/pipermail/nginx-ru/2019-April/062014.html. Я хорошо не изучал этот вопрос, но факт остается, на старой версии openssl ошибок у клиентов в 3-4 раза было меньше. В итоге решили что это клиенты с очень старым ssl. On 27/08/2019 23:25, ngnx8810773a83 wrote: А с какими старыми клиентами не совместим 1.0.2g, который сам тоже не слишком свеж ? В мае был релиз 1.0.2s а g, это гдето в марте 16 года было. Если Вы про sslv2 то оно там есть.у меня специально для этих целей живет нгинкс собранный с 1.0.2m. если кастомный openssl собиратете через сборку nginx с --with-openssl , то ему можно пихнуть кастомные параметры в configure через --with-openssl-opt для всяких оптимизаций. если совсем какито раритеты, то пихните туда enable-weak-ssl-ciphers enable-ssl2.. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285412,285421#msg-285421 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- 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 полностью загружает весь процессор при reload'e
А с какими старыми клиентами не совместим 1.0.2g, который сам тоже не слишком свеж ? В мае был релиз 1.0.2s а g, это гдето в марте 16 года было. Если Вы про sslv2 то оно там есть.у меня специально для этих целей живет нгинкс собранный с 1.0.2m. если кастомный openssl собиратете через сборку nginx с --with-openssl , то ему можно пихнуть кастомные параметры в configure через --with-openssl-opt для всяких оптимизаций. если совсем какито раритеты, то пихните туда enable-weak-ssl-ciphers enable-ssl2.. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285412,285421#msg-285421 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx полностью загружает весь процессор при reload'e
Нашел причину, проблема была в старом ssl - openssl 1.0.1u. perf top показывал: http://dl3.joxi.net/drive/2019/08/27/0030/2608/1985072/72/88257baf85.jpg Попробвал обычную версию 1.0.2g и проблемы ушли. Осталось уговорить менеджеров забить на 1% старых ssl клиентов. On 27/08/2019 18:08, Dmitry Sergeev wrote: Затестил. Без модуля vts тоже самое поведение. -- 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 полностью загружает весь процессор при reload'e
Затестил. Без модуля vts тоже самое поведение. -- 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 полностью загружает весь процессор при reload'e
Еще нюанс забыл указать. nginx компилировал с модулем vts. Возможно с ним проблема. Проверю это. -- 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 полностью загружает весь процессор при reload'e
Прошу прощения, особенности почтового клиента.
Конфиг такой:
user www-data;
worker_processes auto;
worker_cpu_affinity auto;
worker_rlimit_nofile 65000;
pid /var/run/nginx.pid;
events
{
worker_connections 1;
multi_accept off;
}
http
{
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 10;
types_hash_max_size 2048;
server_tokens on;
include /etc/nginx/mime.types;
default_type application/octet-stream;
client_body_timeout 60;
client_header_timeout 60;
send_timeout 60;
reset_timedout_connection on;
##
# Logging Settings
##
access_log off;
error_log /var/log/nginx/error.log;
#
# Caching FS
#
open_file_cache max=1;
open_file_cache_errors on;
##
# Gzip Settings
##
gzip on;
gzip_disable "msie6";
gzip_types text/plain text/css application/json
application/x-javascript text/xml application/xml application/xml+rss
text/javascript application/javascript application/octet-stream;
##
# Maps
##
map $status $status_error
{
"~*^(1|2|3)" 0;
default 1;
}
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
И пример конфига виртуальных хостов для nodejs и php:
upstream nodejs_backend
{
ip_hash;
keepalive 32;
server server1:4201 weight=1;
server server2:4201 weight=3;
}
log_format file_c escape=json
'{"HOST":"$host","LOCATION":"$location","IP":"$remote_addr","PROJECT":"nodejs_backend","HTTP_STATUS":"$status","RESPONSE_TIME":"$request_time","UPSTREAM_CONNECT_TIME":"$upstream_connect_time","UPSTREAM_RESPONSE_TIME":"$upstream_response_time","REQUEST_METHOD":"$request_method","REQUEST_FILE":"$uri","ARGS":"$args","BYTES_SENT":"$bytes_sent","USER_AGENT":"$http_user_agent","HTTP_REFERER":"$http_referer","ENVIRONMENT":"production","AKAMAI_IP":"$http_true_client_ip","HEADER_ACCEPT":"$http_accept","HEADER_ACCEPT_LANGUAGE":"$http_accept_language","HEADER_CONTENT_LANGUAGE":"$http_content_language","HEADER_CONTENT_TYPE":"$http_content_type","BODY":"$request_body"}';
server
{
listen [::]:80;
listen 80;
# SSL
listen [::]:443 ssl http2;
listen 443 ssl http2;
ssl_certificate /etc/nginx/ssl/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/privkey.pem;
server_name nodejs_domain;
root /var/www/nodejs_domain/docroot;
###Logs
# Local logs
access_log /var/log/nginx/nodejs_domain_access.log
file_nodejs_backend if=$status_error;
error_log /var/log/nginx/nodejs_domain_error.log;
location = /robots.txt
{
set $location "robots";
return 200 "User-agent: *\nDisallow: /\n";
}
location = /https:/nodejs_domain
{
set $location "ssl_checker";
return 200 "for ssl checker\n";
}
location ~ /\.(git|svn|hg)
{
deny all;
}
location /
{
try_files /bpcZzfcaG82kpcm9Xxic8hWJ89YjqrJCRihmHGGmBqFnU6gV
@backend;
}
location @backend
{
set $location "nodejs";
proxy_pass http://nodejs_backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_read_timeout 10s;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /.well-known
{
set $location "well-known";
root /usr/share/nginx/html;
}
}
пример конфига для php:
upstream php_backend
{
ip_hash;
server server6:4301 weight=1;
}
log_format file_php_domain escape=json
'{"HOST":"$host","LOCATION":"$location","IP":"$remote_addr","PROJECT":"php_backend","HTTP_STATUS":"$status","RESPONSE_TIME":"$request_time","UPSTREAM_CONNECT_TIME":"$upstream_connect_time","UPSTREAM_RESPONSE_TIME":"$upstream_response_time","REQUEST_METHOD":"$request_method","REQUEST_FILE":"$uri","ARGS":"$args","BYTES_SENT":"$bytes_sent","USER_AGENT":"$http_user_agent","HTTP_REFERER":"$http_referer","ENVIRONMENT":"production","AKAMAI_IP":"$http_true_client_ip","HEADER_ACCEPT":"$http_accept","HEADER_ACCEPT_LANGUAGE":"$http_accept_language","HEADER_CONTENT_LANGUAGE":"$http_content_language","HEADER_CONTENT_TYPE":"$http_content_type","BODY":"$request_body"}';
server
{
listen [::]:80;
listen 80;
listen [::]:443 ssl http2;
listen 443 ssl http2;
ssl_certificate /etc/nginx/ssl/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/privkey.pem;
server_name php_domain;
root /var/www/php_domain/docroot;
access_log /var/log/nginx/php_domain_access.log file_php_domain
if=$status_error;
error_log /var/log/nginx/php_domain_error.log;
location = /robots.txt
{
set $location "robots";
return 200 "User-agent: *\nDisallow: /\n";
}
location = /https:/php_domain
{
set $location "ssl_checker"
Re: nginx полностью загружает весь процессор при reload'e
Hello! On Tue, Aug 27, 2019 at 04:10:31PM +0500, Dmitry Sergeev wrote: > Добрый день. Спасибо за ответ! Пожалуйста. Не надо отвечать мне лично, от этого карма портится. Спасибо. > На сервере всего 64GB памяти, nginx кушает обычно около 2GB при релоадет > не сильно больше - 2-3GB, swap не задействуется. Свободно памяти обычно > больше 60GB. > > Сейчас протестил. При релоаде съедает весь проц ровно 35-40 секунд. > Провел около 10 тестов, время всегда примерно такое. Значит проблема не в памяти, а в чём-то ещё. Что в конфиге? -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx полностью загружает весь процессор при reload'e
Hello! On Tue, Aug 27, 2019 at 03:24:03PM +0500, Dmitry Sergeev wrote: > Версия: 1.14.2 > ОС: ubuntu 16.04 > Процессор: Intel Core i7-6700 CPU 3.40GHz > > Средняя нагрузка: 5 000 rps, пиковые значения 12 000 rps. Статики > практически нет, все запросы проксируются либо на бэкенды с nodejs через > proxy_pass либо на php-fpm через fastcgi_pass. Виртуальных хостов 16, > несколько из них имеют среднюю нагрузку 2K rps, остальные 500 rps. > > С бэкендами nodejs включен keepalive, с php отключен. > > Кроме nginx на сервере ничего нет. > > Проблема в том, что при reload'e конфигурации, несколько минут nginx > начинает жрать весь процессор, все ядра под 100%, и запросы начинают > обрабатываться медленно либо совсем сбрасываются, отсюда куча ошибок у > клиентов. Такая проблема наблюдается только на серверах, где много > виртуальных хостов (15-30). На серверах с аналогичной нагрузкой, но > например 1-3 виртуальными хостами. Таких проблем не наблюдаю. > > Может быть кто-нибудь подскажет, как можно это оптимизировать, что-то > подкрутить. Может можно как-то плавнее релоадить, чтобы медленее, но при > этом нагрузка на CPU как-то плавнее распределялась. Для начала - имеет смысл посмотреть на количество доступной памяти. При релоаде количество рабочих процессов увеличивается вдвое, и если памяти мало - система может уходить в свап с печальными последствиями. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
nginx полностью загружает весь процессор при reload'e
Версия: 1.14.2 ОС: ubuntu 16.04 Процессор: Intel Core i7-6700 CPU 3.40GHz Средняя нагрузка: 5 000 rps, пиковые значения 12 000 rps. Статики практически нет, все запросы проксируются либо на бэкенды с nodejs через proxy_pass либо на php-fpm через fastcgi_pass. Виртуальных хостов 16, несколько из них имеют среднюю нагрузку 2K rps, остальные 500 rps. С бэкендами nodejs включен keepalive, с php отключен. Кроме nginx на сервере ничего нет. Проблема в том, что при reload'e конфигурации, несколько минут nginx начинает жрать весь процессор, все ядра под 100%, и запросы начинают обрабатываться медленно либо совсем сбрасываются, отсюда куча ошибок у клиентов. Такая проблема наблюдается только на серверах, где много виртуальных хостов (15-30). На серверах с аналогичной нагрузкой, но например 1-3 виртуальными хостами. Таких проблем не наблюдаю. Может быть кто-нибудь подскажет, как можно это оптимизировать, что-то подкрутить. Может можно как-то плавнее релоадить, чтобы медленее, но при этом нагрузка на CPU как-то плавнее распределялась. -- 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
