<div dir="ltr"><div>Сокеты в основном в stream, поэтому их агрегировать не получится, как я понимаю, с  http то проблем нет.</div><div><br></div><div>Парзинг конфига занимает около секунды, а вот знание того, что получился невалидный конфиг очень помогает избежать простоев.</div><div><br></div><div>Основная проблема в долгом syscall bind, который долгий при определенных обстоятельствах. И почему он долгий не понятно.</div><div>в strace видно время вызовов и видно, что для бинда по 443 порту оно в сотни раз дольше, чем для других портов.</div></div><br><div class="gmail_quote"><div dir="ltr">вт, 13 нояб. 2018 г. в 21:58, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<br>
On Tue, Nov 13, 2018 at 08:23:03PM +0300, kpoxa wrote:<br>
<br>
> Добрый день.<br>
> <br>
> Есть сервер (Dual Xeon E5620, средняя нагрузка проца в праймтайм 20%) с<br>
> nginx в главной и по сути единственной роли, задача которого проксирование<br>
> и больше ничего.<br>
> <br>
> В конфиге 101 listen на уникальные ip:port, nginx без сторонних модулей.<br>
> 1.15.4, но думаю что версия тут не при чем.<br>
> Debian Linux Jessy с ядром 3.16.<br>
> <br>
> В среднем одновременных коннектов открыто 150-200 тыс. 70% из них по 443<br>
> порту.<br>
> в логе собирается время отвремя апстрима и было замечено, то раз в 30<br>
> секунд оно пролагивает у части коннектов на лишнюю секунду, т.е. обычно<br>
> 0.01, а тут 1.01 сек.<br>
> Выяснилось что раз в 30 секунд срабатывает проверка конфига заббиксом, т.е.<br>
> вызывается<br>
> nginx -t<br>
> <br>
> Ручной вызов nginx -t привел к появлению в логах лагающих  запросов в это<br>
> время, выключение аббикс агента такие запросы убирает вообще.<br>
> команда<br>
> time nginx -t<br>
> nginx: the configuration file /etc/nginx/nginx.conf syntax is ok<br>
> nginx: configuration file /etc/nginx/nginx.conf test is successful<br>
> real    0m0.601s<br>
> user    0m0.044s<br>
> sys     0m0.432s<br>
> показывает 0.4 с лишним секунды в режиме ядра.<br>
> а попытка разобраться чем же занято ядра выдало ниже следующее<br>
> <br>
> strace -Ttt nginx -t 2>&1 | grep bind<br>
> <br>
> т.е. bind на 443 порты занимает 15 тысячных секунды, против стотысячных<br>
> долей у прочих биндов.<br>
> <br>
> Есть ли идеи, как решить проблему пролагиваний при проверке конфига?<br>
> Вариант убрать её из заббикса считаю академически неправильным, просьба его<br>
> не рассматривать.<br>
> <br>
> reuseport не используется, может он помочь?<br>
<br>
Из общих соображений я бы скорее предположил, что reuseport в <br>
данной ситуации сделает хуже, а не лучше.  Потому что сокетов <br>
станет только больше, а bind() должен проверить конфликты с <br>
открытыми сокетами.<br>
<br>
Очевидное решение - добавить listen на *:443, тогда listen-сокет <br>
будет один, и проблема исчезнет.<br>
<br>
Впрочем, запускать "nginx -t" раз в 30 секунд - это, скажем так, <br>
очень странное решение, если не сказать грубее.  Особенно с учётом <br>
того, что только парсинг конфигурации вполне может занимать <br>
несколько минут.<br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></blockquote></div>