<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<pre class="moz-quote-pre" wrap="">Добрый день!
Спасибо за ответ.
Конфиг полный, просто сократил количетсво виртуальных хостов, так как они одинаковые.
ssl_session_cache - действительно не настроено.
ssl_dhparam - аналогично.
сертификат один общий для всех, сгенерировал его для wildcard домена от let's encrypt (Signature Algorithm: sha256WithRSAEncryption, Public-Key: rsaEncryption (2048 bit)).
Пытался оптимизировать ssl и посмотреть влияние его настроек на эту проблему. В частности пробовал глобально добавлять опции:
<strong>ssl_session_cache shared:SSL:20m;</strong>
<strong>ssl_session_timeout 30m;
</strong>вроде никак не влияло, но я проверю еще раз конечно, и более чательно.
Про ssl_dhparam не понял, с точки зрения производительности - его лучше добавлять но с небольшой битностью (2048 и меньше) или лучше совсем не использовать?
Большое спасибо за советы.
<strong></strong></pre>
<div class="moz-cite-prefix">On 30/08/2019 17:49, Maxim Dounin
wrote:<br>
</div>
<blockquote type="cite" cite="mid:20190830124912.GE1877@mdounin.ru">
<pre class="moz-quote-pre" wrap="">Hello!
On Wed, Aug 28, 2019 at 09:18:44PM +0500, Dmitry Sergeev wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Вообще мне это конечно помогло, но не полностью. На версии 1.0.2g во
время reload'а проц грузит полностью около 5-10 секунд (вместо 40-300
секунд на 1.0.1u), теперь просто оно особо проблем не вызывает у
клиентов. Но в целом проблема осталась, просто теперь она не так сильно
беспокоит.
Сейчас задача замедлилась, но в итоге буду поднимать тестовый стенд с
нагрузкой, и смотреть можно ли как-то повлиять на это.
Если конечно тут не подскажут, что еще можно подкрутить.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Судя по perf top, проблема в том, что клиенты после reload'а
переустанавливают соединения, и это выливается в полный SSL
handshake - что и приводит к потреблению CPU.
Посмотреть стоит на:
- ssl_session_cache - в конфиге его, судя по всему, нет (или
соответствующие части конфига не показаны);
- сертификаты, в частности - их битность (just in case, RSA более
2048 использовать не надо, это тупо очень дорого с точки зрения
процессора) и тип (лучше использовать ECDSA, но тут уже может
встать вопрос совместимости; при желании можно использовать и RSA
и ECDSA одновременно);
- используемые шифры, особенно - шифры с классическим DH для
обмена ключами (по умолчанию эти шифры не используются начиная с
nginx 1.11.0, но некоторые любят указывать ssl_dhparam в конфиге,
да ещё и с параметрами большой битности; не надо так);
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Насчет старых клиентов, точно не могу сказать, но есть такой кейс
<a class="moz-txt-link-freetext" href="http://mailman.nginx.org/pipermail/nginx-ru/2019-April/062014.html">http://mailman.nginx.org/pipermail/nginx-ru/2019-April/062014.html</a>. Я
хорошо не изучал этот вопрос, но факт остается, на старой версии openssl
ошибок у клиентов в 3-4 раза было меньше. В итоге решили что это клиенты
с очень старым ssl.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Как уже говорилось в треде по ссылке, использование OpenSSL
1.0.1u автоматически означет, что HTTP/2 с большинством клиентов
работать не будет. С учётом "listen ... http2" в конфиге -
обновление до 1.0.2 могло "помочь" просто за счёт того, что HTTP/2
заработал, и количество устанавливаемых соединений соответственно
уменьшилось.
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Kind regards
Dmitry Sergeev
Tel: +7 (951) 129-75-72</pre>
</body>
</html>