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

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

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