Добрый день!
Спасибо за ответ.

Конфиг полный, просто сократил количетсво виртуальных хостов, так как они 
одинаковые.

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

Ответить